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Computer  i>e l inition 

The  I’ransact ion  Processing  Operating  System  is 
designed  to  execute  within  a Honeywell  Series  6000  or 
Series  60/I,evel  66  Information  System,  with  any 
allowable  memory  size.  One  DATANET  30,  305,  355,  or 
6600  or  355  Communications  Processor  is  required  to 
perform  front-end  processing  functions  and  at  least  one 
of  the  following  terminals  is  required:  Teletype  Models 
33,  35,  37,  or  38;  GE  TermiNet  300;  VIP  Series  765, 
775,  785,  7700  keyboard/display  terminals. 


System  Definition 


The  Transaction  Processing  Operating  System  (TPOS) 
IS  designed  to  operate  under  Release  2/H  of  the  General 
Comprehensive  Operating  Supervisor  (GCOS) , the  General 
Remote  Terminal  Supervisor  (GRTS)  or  the  Network 
Processing  Supervisor  (NPS)  and  in  conjunction  with  the 
Transaction  Processing  System  (TPS). 
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EVALUATION 


This  effort  has  provided  a number  of  important  enhancements  designed 
to  improve  the  operational  capability  of  the  Transaction  Processing  Operating 
System  (TPOS)  which  executes  under  the  ('.COS  Operating  System  on  the  H6000 
Computer  System. 

The  establishment  of  a sophisticated  programming  environment  for 
command  and  control  applications  is  a criteria  defined  under  TPO  V 3.5. 

Within  this  environment,  a requirement  exists  for  real-time  p>-ocessing  on 
the  H6000  computer  architecture.  Tlte  TPOS  system  provides  a vehicle  to 
process  in  a real-time  mode  a number  of  transactions  to  a wide  variety  of 
previously  defined  data  structures.  The  TPOS  system  also  provides  the 
following  capabilities: 

. Ability  to  tailor  the  environment  to  the  specific  transaction 
processing  needs  of  a user. 

Reduction  in  the  mimbL'i'  o!  programs  dedicated  to  a user's 
site  transaction  processing  requirements. 

.Multiple  concurrent  execution  of  the  same  Transaction  Processing 
Application  Programs. 

Tlie  capability  provided  by  the  TPOS  system  can  he  immediately 
utilized  by  a wide  variety  of  current  applications  which  execute  under 
control  of  the  lUiOOO  Transaction  Processor.  It  can  provide  a means 
of  defining  a real-time  programming  environment  within  large  scale 
coraput er  architectures. 


RAYMOND  A.  LIUZZI 
Project  Engineer 
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PURPOSE 


PURPOSE 


The  purpose  of  the  Transaction  Processing 

Operating  System  is  to: 

(1)  Allow  multiple  copies  of  the  sami.  Transaction 
Processing  Applications  Program  (TPAP)  to 
execute  concurrently, 

(2)  Increase  transaction  processing 

responsiveness, 

(3)  Create  the  necessary  framework  for  efficient 
control  and  interface  of  TPAPs  to  a common 
data  base, 

(4)  Provide  a specialized,  open-ended  environment 
that  can  be  tailored  to  specific  transaction 
processing  needs. 

In  addition,  the  operating  system  allows  a 

reduction  in  the  number  of  GCOS  Program  Numbers 
dedicated  to  a site's  transaction  processing 

requirements. 
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TRANSACTION  PROCESSING  OPERATING  SYSTEM 


The  TPAP  Operating  .system  (TPuS)  is  a specialized 
system  designed  to  ■..ontrol  a subset  of  the  total 
computer  environment  for  the  exclusive  execution  of 
Transaction  Processing  Applications  Programs  (TPAPs) . 
This  operating  system  is  by  no  means  a comprehensive 
computer  operating  system;  however,  it  must  perform 
many  of  the  executive  or  control  functions  required  of 
the  latter.  The  TPAP  Operating  System  executes  under 
GCOS  as  a slave  program.  In  this  context,  it  resembles 
the  Time-Sharing  System. 


The  TPAP  Operating  System  interfaces  with  the 
Transaction  Processing  System  as  a TPAP.  Consequently, 
the  TPOS  is  known  to  the  Transaction  Processing 
Executive  (TPE)  as  just  another  TPAP.  This  arrangement 
allows  several  TPAP  Operating  Systems  to  be 
incorporated  into  the  Transaction  Processing  System. 


Transaction  Processing  Operatinc 


astern  Executive 


The  TPAP  Operating  System  Executive  consists  of 
those  routines  that  perform  the  executive  or  control 
functions  which  are  typical  of  any  standard  operating 
system.  In  particular,  these  functions  include  the 
initiation,  monitoring  and  control  of  system 
operations,  resource  allocation  and  processing  support. 


In  the  current  state 
Operating  System  and  the 
Executive  are  synonymous, 
interchangeably.  Henceforth, 
is  referred  to  as  simply  the 


of  development,  the  TPAP 
TPAP  Operating  System 
thus  the  names  can  be  used 
the  TPAP  Operating  System 
Execu  t ive . 


Introduction  to  the  Executive 


As  previously  stated,  the  Executive  is  a slave 
program  which  operates  within  the  Transaction 
Processing  System  as  a standard  TPAP.  The  Executive 
functions  as  the  operating  supervisor  for  some  number 
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of  TPAPs  within  a GELBAR  environment.  That  is,  the 
Executive  overlays  the  TPAPs  into  a portion  of  its 
allocated  memory  and  passes  control  to  the  TPAPs  via 
the  MME  GELBAR  logic.  Because  the  GELBAR  changes  the 
BAR  to  the  requested  setting,  both  the  Executive  proper 
and  any  other  TPAPs  residing  within  the  Executive's 
core  are  protected  from  memory  access  by  the  executing 
TPAP. 


TPAPs  that  are  to  execute  under  the  control  of  the 
Executive  are  generically  called  Keyword  Processors. 
Since  the  Keyword  Processors  can  be  written  exactly 
like  a normal  TPAP,  this  label  serves  solely  to 
differentiate  between  the  two  methods  of  execution. 


The  Keyword  Processors  are  maintained  on  high 
speed  storage  from  which  they  can  be  retrieved  when 
requested  by  an  input  transaction.  Multiple  copies  of 
the  same  Keyword  Processor  are  possible  since  each 
input  transaction  designates  to  the  Executive  which 
Keyword  Processor  is  to  be  executed,  independent  of  the 
other  transactions  being  serviced.  Thus  each 
transaction  effectively  gets  its  own  copy  of  the 
requested  Keyword  Processor. 


All  files  must  be  allocated  to  the  Executive, 
since  the  Keyword  Processors  are  loaded  without  an  SSA. 
This  requirement  allows  all  the  Keyword  Processors  to 
access  any  data  base  allocated  to  the  Executive  and 
creates  the  necessary  framework  for  efficiently 
controlling  multiple  data  base  access  requests. 


The  Executive  is 
major  functions: 


responsible 


for  the  following 


o Receiving  multiple 
Intercom  I/O  from 
Keyword  Processor 
transact  ion. 


input  transactions  via 
TPE  and  scheduling  the 
identified  by  the 


o Allocating  core  and  processor  time  on  a 
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priority  basis  to  the  scheduled  Keyword 
Processors . 


o Processing  Keyword  Processor  program  faults 
and  service  requests  by  trapping,  identifying 
and  routing  the  fault  to  the  applicable 
Executive  routine.  In  particular,  all  Keyword 
Processor  requests  for  GCOS  system  services 
are  trapped,  since  MMEs  and  DRLs  generate 
faults.  Thus  all  I/O  requests  are  intercepted 
and  handled  by  the  Executive. 

o Collecting  and  queueing  output  Intercom 
messages  from  the  Keyword  Processors  and 
initiating  Intercom  I/O  for  each  message  when 
the  processing  for  its  related  transaction  is 
complete . 

Overview 


The  Transaction  Processing  Opera 
Executive  monitors  and  controls  its  compu 
in  order  to  enable  a set  of  programs. 
Processors,  to  operate  concurrently.  Its 
be  logically  divided  into  a set  of  modu 
whose  functions  are  briefly  described  in 
paragraphs. 
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Input  processing  is  performed  for  the  Executive  by 
the  Transaction  Scheduler.  The  Transaction  Scheduler 
will  request  a message  from  the  TPE  whenever  sufficient 
Input  Intercom  Buffer  space  and  a free  Transaction 
Attributes  and  Status  Kernel  (TASK)  are  available.  A 
TASK  functions  as  the  focal  point  for  all  the  dynamic 
information  required  to  control  the  processing  of  a 
transaction  by  its  associated  Keyword  Processor.  A TASK 
is  assigned  to  each  transaction  received  by  the 
Executive. 


When  an  input  message  is  accepted,  the  Keywords 
List  is  scanned.  This  list  contains  the  keywords  for 
all  Keyword  Processors  assigned  to  the  Executive.  If 
the  keyword  is  not  in  the  list,  an  error  message  is 
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returned  to  the  user  and  the  transaction  is  deleted. 
Otherwise,  the  Keyword  Processor  attributes  are 
retrieved  from  the  Keyword  Processor  Profile  table  and 
inserted  into  the  TASK.  The  TASK  is  then  linked  to  the 
Core  Allocator's  Core-Queue  and  an  attempt  is  made  to 
request  another  message. 


The  Core  Allocator  selects  TASKS  in  priority  order 
and  attempts  to  allocate  a sufficient  amount  of  core  in 
which  the  Keyword  Processor  can  execute.  It  will 
generally  use  the  smallest  block  of  available  core  to 
make  this  allocation.  If  core  is  not  available,  but  can 
be  obtained  by  swapping-out  an  in-core  Keyword 
Processor  that  meets  the  criteria  for  swap-eligibility, 
then  the  Keyword  Processor  swap  is  initiated. 
Otherwise,  the  TASK  is  bypassed  and  the  next  TASK  in 
priority  sequence  is  considered  for  allocation.  This 
process  is  repeated  until  the  end  of  the  Core-Queue  is 
reached.  The  bypass  count  (initially  set  from  the 
Keyword  Processor  Profile)  of  each  TASK  in  the  queue  is 
reduced  by  one  whenever  core  is  allocated  to  a lower 
priority  TASK.  If  the  bypass  count  for  a particular 
TASK  is  zero  or  is  reduced  to  zero,  no  lower  priority 
TASK  will  be  considered  by  the  Core  Allocator.  When  no 
more  TASKS  can  be  allocated  core,  control  is  given  to 
the  Dispatcher. 


The  Dispatcher  is  responsible  for  assuring  that 
all  Executive  functions  are  performed.  it  receives 
control  every  time  a Keyword  Proessor  terminates, 
requests  an  Executive  service,  or  runs  out  of  time. 


The  flow  of  all  transact 
Transaction  Processing  Operating  Sys 
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The  Dispatcher  must  also  select  the  highest 
priority  TASK  in  the  Dispatcher ' s-Queue  and  give  it 
control  via  a MME  GELBAR,  which  provides  core  and  time 
limits  to  the  TASK. 


All  Keyword  Processors  are  expected  to  perform  I/O 
via  a MME  GEINOS  request,  as  is  done  by  most  system 
subroutines  such  as  GFRC.  Since  GELBAR  logic  intercepts 
all  MMEs,  no  Keyword  Processor  can  perform  I/O  without 
the  Executive's  permission.  For  MME  GEINOS,  parameters 
are  validated  and  DCW s are  adjusted  to  account  for  the 
GELBAR  boundaries.  In  the  case  of  device  I/O,  the  I/O 
is  reissued  by  the  Executive  and  the  Keyword  Processor 
is  roadblocked  until  the  I/O  has  completed. 


For  Intercom  I/O  writes,  every  Keyword  Processor 
must  include  an  indicator  within  each  output  message 
which  specifies  if  the  text  is  a segment  (more  text  in 
the  message)  an  End-Of-Message , or  an 
End-Of-Transact ion , as  dictated  by  standard  TPAP  logic. 
The  Executive  collects  message  segments  until  an 
End-Of-Message  or  an  End-Of-Transaction  status  is 
received.  On  either  status,  the  Executive  links  each  of 
the  segments  successively  (no  intervening  segments  from 
another  TASK)  into  the  output  stream.  It  is  necessary 
to  link  these  successively  to  assure  that  the  segments 
arrive  at  their  destination  in  proper  sequence. 


If  the  End-Of-Transaction  indicator  is  specified, 
the  Keyword  Processor  is  prohibited  from  generating 
additional  output  messages.  However,  the  Keyword 
Processor  will  be  given  control  so  it  can  perform  any 
wrap-up  which  may  be  necessary.  Following  this, 
standard  procedure  is  for  the  Keyword  Processor  to 
reinitialize  itself  up  to  and  including  its  request  for 
another  transaction. 


At  this  point  the  Keyword  Processor  has  completed 
its  processing  of  the  transaction  assigned  to  it; 
consequently,  it  is  suspended  from  further  execution  by 
the  Executive.  If  the  Keyword  Processor  is  reusable 
(i.e.,  can  process  multiple  transactions  serially),  and 
there  is  an  outstanding  input  message  for  the  keyword 
associated  with  it,  the  new  message  is  assigned  to  the 
Keyword  Processor  and  it  is  again  eligible  for 
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execution.  Otherwise,  reusable  or  not,  the  Keyword 
Processor  is  terminated  and  effectively  disposed  of.  In 
this  case  and  for  all  non-reusable  Keyword  Processors, 
a new  copy  of  the  Keyword  Processor  will  be  initiated 
for  a subsequent  input  message  that  specified  the 
Keyword  Processor. 

There  also  exists  the  capability  for  the  Keyword 
Processors  to  communicate  among  themselves  by 
transmitting  an  output  message  with  a single 
Destination-ID  of  ***.  This  capability  is  restricted  to 
internal  communication  among  the  Keyword  Processors 
that  are  controlled  by  the  Executive. 
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Introduction 


This  section  is  concerned  with  the  necessary  site 
operations  that  are  required  to  generate,  install  and 
run  a TRAP  Operating  System.  The  major  steps  that  are 
required  to  set  the  system  into  motion  are 
chronological ly  listed  below; 


o Requesting  the  user-supplied  Keyword 
Processor  programs  and  characteristics 


o Assembling  the  Executive  with  the  desired 
parametric  structure  and  the  Keyword 
Processor  characteristics 


o Creating  and  loading  the  Keyword  Processor 
Library 


o Installing  the  Executive  within  TPE. 


The  above  steps  are  further  explained  in  the 
discussions  that  follow.  Those  methods  presented  in  the 
discussions  are  only  meant  to  be  a guideline  showing 
one  of  many  possible  methods. 


Lastly,  it  should  be  emphasized  that  there  can  be 
several  TPOSs,  since  each  system  externally  resembles  a 
normal  TRAP. 
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User  Suppl led  Information 


The  user  is  responsible  for  supplying  the  Keyword 
Processor  programs  and  the  control  parameters,  which 
are  required  by  the  Executive.  Some  of  the  control 
information  must  be  coordinated  among  all  users  whose 
transaction  processing  programs  are  to  be  installed 
under  the  same  Executive. 


All  Keyword  Processor  programs  should  be  suitable 
tor  a lowload,  since  the  Executive  unconditionally 
lowloads  all  Keyword  Processors.  The  programs  should  be 
submitted  in  relocatable  object  form,  such  as  the  $ 
OBJECT  deck  produced  by  a compilation. 


The  user  must  also  supply  the  control  information 
that  defines  the  Keyword  Processor  and  its  file 
environment . In  particular,  the  user  must  submit  the 
following : 


(1)  Keyword-Processor-ID  - this  is  a three 
character  ID  that  uniquely  identifies  the 
Keyword  Processor  from  other  Keyword 
Processors  assigned  to  the  Executive, 


(2)  Maximum  input  and  output  message  sizes 

these  sizes  should  include  the  message 
headers  and  be  given  in  words. 


(3)  Keywords  - these  are  the  keywords  to  be 
associated  with  the  Keyword  Processor.  All 
Keywords  must  be  eight  characters  or  less  in 
size. 


In  addition  to  the  above  Keyword  Processor 
intormation,  the  user  must  also  supply  the  expected 
file  requirements.  This  should  include  the  necessary  $ 
FILE  control  cards  along  with  any  $ USERID  control 
cards  that  would  be  required  to  attach  the  files  to  the 
Executive. 
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Notice  that  the  Keyword-Pr ocessor-lD , Keywords  and 
the  File-Code  assignments  should  be  coordinated  among 
the  users  to  ensure  that  there  will  not  be  any 
conf 1 icts . 


The  Executive  must  be  assembled  to  incorporate  the 
necessary  Keyword  Processor  information  and  to 
parametrically  tailor  the  Executive  to  the  anticipated 
transaction  processing  needs. 


All  user  supplied  information  regarding  the 
Keyword  Processors  is  inserted  into  the  Executive  by 
means  of  the  Keyword  Processor  Profile  macro.  This 
macro  is  symbolically  denoted  by  .PRFL..  Actual  use  of 
the  macro  is  described  in  the  Keyword  Processor  Profile 
discussion. 


Of  particular  importance  to  the  site  personnel  are 
the  priority  and  bypass  count  assignments.  Prior  to 
assigning  the  values,  the  importance  of  each  Keyword 
Processor,  relative  to  all  other  Keyword  Processors  to 
be  controlled  by  the  Executive,  must  be  established. 

Priorities  within  the  Executive  are  currently 
pre-emptive,  consequently,  the  priority  values  are 
meaningful  only  in  terms  of  their  algebraic 
relationships  and  not  their  individual  magnitudes.  For 
example,  there  would  be  no  operational  difference 
between  different  sets  of  Keyword  Processor  priority 
assignments  as  long  as  the  relationships  between  the 
assigned  values  were  the  same. 

Bypass  count  assignment  is  more  difficult.  The 
purpose  of  the  bypass  counts  is  to  allow  the  Executive 
to  temporarily  ignore  a priority  value  during  core 
allocation,  thereby  allowing  more  efficient  core 
utilization  and  system  throughput. 


The  bypass  count  should  be  set  to  zero  for  only 
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the  most  urgent  Keywords  or  Keyword  Processors.  For  the 
remainder  of  the  keywords,  the  bypass  counts  should 
primarily  reflect  the  size  of  the  associated  Keyword 
Processor  and  secondarily,  the  amount  of  time  normally 
required  to  process  a transaction.  That  is,  the  larger 
the  Keyword  Processor  the  larger  the  bypass  count; 
among  Keyword  Processors  of  the  same  size,  the  slower 
the  processing  the  larger  the  bypass  count.  Of  course, 
a large  bypass  count  should  not  be  assigned  to  a high 
priority  keyword  even  if  the  Keyword  Processor  is  large 
or  slow. 


It  is  anticipated  that  some  experimenting  with  the 
bypass  counts  will  be  necessary  in  a heavy  transaction 
processing  environment  to  achieve  a satisfactory 
throughput  rate.  However,  if  the  processing  workload  is 
light  to  moderate,  the  effect  of  the  bypass  count  is 
negligible. 


The  parametric  structure  of  the  Executive  is 
defined  by  the  series  of  macros  listed  below: 


.BUFF.  Generate  Input/Output  Intercom  Buffer 

Space 

.COMQ.  Generate  Output  Intercom-Queue  Space 

.LINE.  Generate  Terminal  Control  Block  & Buffer 
Space 

.MSG.  Set  Maximum  Input  S-  Output  Intercom 

Message  Sizes 

.SWAP.  Generate  Swap-File  Map  Space 
.TASK.  Set  TASK  Size  & Generate  TASK  Space 
•TPOS.  Set  TPOS  Options 

See  Installation  Macro  usage  for  an  explanation  of  how 
to  use  the  above  macros. 
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Keyword  Processor  Library 

A special  file  must  be  created  for  each  Executive 
to  hold  the  Keyword  Processor  programs  which  are  under 
its  control.  This  file  is  called  the  Keyword  Processor 
Library  File  and  is  assigned  the  file  name  L-xxx,  where 
XXX  is  the  TPAP-ID  assigned  to  the  Executive  in  TPE. 
This  naming  convention  allows  each  Executive  to  be 
conveniently  associated  with  its  library  file. 
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Creating  the  Keyword  Processor  Library 

The  control  card  setup  to  create  a library  is  as 
f ol lows : 


1 8 16 

$ SNUMR 

$ I DENT 

$ FILSYS 

USERID  TRAX-EXEC$Password 
FCREAT  TRAX-EXEC/L-xxx,SIZE/n, n/ 

5 ENDJOB 

***EOF 

where  xxx  is  the  TPAP-ID  of  the  controlling  Executive. 


Gener at  ing  the  Keyword  Processor  Library 


Within  the  Keyword  Processor  Library,  the  program 
element  names  for  the  Keyword  Processor  programs  are  of 
the  form  S.yyy,  where  yyy  is  the  Keyword-Processor-ID 
internal  to  the  Executive.  The  Executive  retrieves  the 
Keyword  Processors,  during  initialization,  by 
performing  a GECALL  with  the  desired  S.yyy  name  to  the 
1 ibrary . 
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The 
onto  the 


first  Keyword  Processor  program  can  be  loaded 
library  with  the  following  control  card  setup: 


1 8 16 


$ SNUMB 

$ IDENT 

$ LOWLOAD 

$ OPTION  SAVE/S. yyy,NOGO 

$ LANGUAGE 

(KEYWORD  PROCESSOR  PROGRAM) 

$ EXECUTE 

$ PRMFL  H*,R/W,R,TRAX-EXEC/L-xxx 

$ LIMITS 

$ ENDJOB 

***EOF 


where  yyy  is  the  Keyword-Pr ocessor-ID  and  xxx  is  the 
Executive's  TPAP-ID. 


For  subsequent  Keyword  Processors,  the  SAVE  option 
must  be  replaced  with  the  SAVOLD  option. 


Notice  that  since  TPE  requires  the  TPAP  files  to 
be  in  spawn  format,  i.e.,  a control  card  deck,  a 
Keyword  Processor  can  also  be  executed  as  a normal  TPAP 
by  inserting  a $ PROGRAM  card,  which  specifies  the 
S.yyy  Keyword  Processor  name.  Such  a deck  also  has  to 
specify  the  Keyword  Processor  Library  as  a dynamic 
user's  library.  In  this  case  a TPAP  Profile  would  also 
have  to  exist  within  TPE  for  the  Keyword  Processor. 
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Executive  Installation 


Each  Executive  must  be  installed  into  the 

Transaction  Processimj  System  l)y  assembling  a TPAP 
Profile  into  module  TRXD  of  TPE  to  specify  the 

operating  character ist ics  of  the  Executive  and  by 
creating  and  loading  a TPAP  File  to  hold  the 

Executive's  spawn  deck.  The  installation  procedure  is 
described  in  the  Transaction  Processing  System  Site 
Manual  (Order  No.  nD36) . 


The  necessary  operating  parameters  to  be  supplied 
to  the  TPAP  Profile  macro  are: 


(1)  Executive's  TPAP-ID 

(2)  Input  and  output  buffer  sizes 

(i)  All  keywords  belonging  to  the  Keyword 

Processors  assigned  to  the  Executive  along 
with  their  associated  priorities 

(4)  Accept  ***STRT  message 

(5)  BCD  input  and  output 

(6)  Maintain  select/dispatch  order 

(7)  No  swap 

(8)  Accept  multiple  input  messages 

The  buffer  sizes  are  the  sizes  used  in  the 
Executive's  .MS(!.  macro  previously  described. 

The  necessary  information  that  must  be  included  on 
the  TPOSs  TPAP  File  is: 


(1)  $ LIMITS  card  specifying  the  amount  of  memory 
to  be  assigned  to  the  Executive. 

(2)  $ PRMFL  card  to  attach  the  Keyword  Processor 
Library  as  a user's  dynamic  library  with  File 
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Code  **. 

(3) 

$ FILE  card  to  attach  space 
Load-File. 

for 

the 

$L 

(4) 

$ FILE  card  to  attach  space 
Swap-File . 

for 

the 

$S 

(5) 

All  file  cards  supplied  by  the 
Keyword  Processors  themselves. 

user 

for 

the 

The  amount  of  memory  to  be  allocated  to  the 
Executive,  as  requested  on  the  $ LIMITS  card,  should 
take  into  account  the  size  of  the  Executive  as 
determined  from  its  assembly. 


The  $L  Load-File  holds  the  Keyword  Processors 
during  the  Executive's  execution,  since  they  can  be 
retrieved  from  it  faster  than  from  the  library. 
Consequently,  sufficient  space  must  be  allocated  to  the 
file  to  hold  all  the  Keyword  Processors.  Any  excess 
space  is  released  at  the  end  of  the  Executive's 
initial ization. 


The  TPOS  TPAP  File  can  contain  the  Executive  in  $ 
OBJECT  form  or  it  can  specify  an  object  library  onto 
which  the  Executive  has  been  edited.  Independent  of  the 
actual  method  used,  a sample  control  card  make-up  for 
the  TPAP  File  is  as  below: 

1 8 16 

$ IDENT  (Optional) 

$ USERID  TRAX-EXEC$Password 

$ LOWLOAD 

$ OBJECT 

(TPOS  EXECUTIVE) 

$ DKEND 
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$ 

$ 

$ 

$ 

$ 

$ 

$ 

$ 

$ 


LINK  INIT  I 

I 

OBJECT  j 

J 

TPOS  INITIALIZATION 
DKEND 

EXECUTE  DUMP 


LIMITS 

, Memory-S  ize 

PRMFL 

**,R,R,TRAX-EXEC/L-xxx 

Keyword 

Processor 

Library 

FILE 

$L, ,Size 

Keyword 

Processor 

Load-File 

FILE 

$S , , S ize 

Keyword 

Processor 

Swap-File 

FILE 

Keyword 
Processor 
Fi  les 

$ FILE 

$ ENDJOB 

Executive  Initiation 


Frequently  used  or  priority 
and  remain  in  the  GCOS  program 
priority  programs  causes  them 
relatively  slow  peripheral  and 
making  them  available  for  immedi 
GCOS  swap  file. 


TPAPs  are  prespawned 
queue.  Prespawning  the 
to  pass  through  the 
core  allocation  phase, 
ate  execution  from  the 


Each  Executive  can  be  explicitly  spawned  by 
issuing  a dummy  message  with  the  appropriate  keyword  or 
implicitly  spawned  at  the  system  console  or  master 
terminal  via  the  RESTORE  ***  Command.  This  command  will 
spawn  each  TRAP  whose  profile  contains  flag  word  bit 
0=1  with  the  message  ***  STRT.  The  Executive  recognizes 
this  message,  performs  its  initialization  functions  and 
sends  an  End-of-Transact ion  status  to  TPE. 


During  the  spawning  phase,  those  files  specified 
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in  the  TRAP  File,  are  attached  to  the  Executive.  These 
files  reflect  all  files  to  be  managed  by  the  Executive 
or  accessed  by  the  Keyword  Processors, 
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Master  Terminal  Capabilities 

TPOS  has  master  terminal  capabilities  which  are 
used  via  a DAC  connect  to  TPOS.  There  are  five  master 
terminal  program  functions: 

Statistics 

Debug 

Line  Switch 
Terminal  Hold 
Termination 


The  master  terminal  capabilities  are  entered  via  a 
DAC  connect.  For  example,  the  "JDAC"  command  in  time 
sharing  could  be  used  to  connect  to  TPOS: 

JDAC  TPOS 

TPOS  will  issue  a connect  message  in  the  following 
format : 

**TPOS:  MM/DD/YY  at  HH:MM:SS:  ON  CHANNEL  CCCC 


MM 

= 

Month 

LD 

Day 

YY 

= 

Year 

HH 

= 

Hour 

MM 

= 

Minute 

SS 

= 

Seconds 

CCCC 

- 

Channel  Number 

At  this  time  TPOS  asks  which  of  the  four  "programs"  you 
wish  to  enter.  The  message  has  the  format: 

PROGRAM  NAME  ? 

In  response,  one  may  enter: 

STATS  - Statistics 

DBUG  - Debug 

LSwrr  - Line  Switch 

WAIT  - Terminal  Hold 

BYE  - Termination 
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the 


Because  of  the  nature  of  the  information, 
systems  require  passwords,  which  are: 


two  of 


Program 

STATS 

DBUG 


Password 

NUMBERS 

WELCOME 


NOTE:  All  commands  must  be  entered  with  "UPPER  CASE". 


Statistics 

TPOS  has  a master  statistics  capability.  The 
current  statistical  functions  are: 


TPOS  U 
TPOS  C 
TPOS  A 

TPOS 


List  TPOS  Usage  Information 
List  TPOS  Communication  Counts 
List  both  TPOS  Usage  Information 
and  communication  Counts 
Defaults  to  TPOS  A 


In  addition  to  the  above  functions,  continuous 
monitoring  may  be  obtained  by  the  use  of  an  asterisk 
(*)  after  the  commands.  For  example: 

TPOS  U* 

TPOS  C* 

TPOS  A* 

Statistical  monitoring  in  continuous  mode  may  be 
interrupted  by  use  of  the  break  function  on  a terminal 
(S*$BRK  on  a CRT) . 

Upon  completion  of  the  statistical  monitoring,  the 
statistical  program  is  terminated  by  use  of  the  "DONE" 
command . 


Debug 

TPOS  has  a master  debug  capability.  This 
capability  is  accessed  via  a DAC  connect  to  TPOS.  The 
current  debug  functions  are: 
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Sal-a2 
Sa , n 
SR 


Patch 


Snap  from  al  to  a2 
Snap  n words  starting  at  a 
Snap  processor  registers  in  dump 
format 

Snap  breakpoint  table 


Pa  pi , . . . , pn 
PVa  pi , . . . , pn 


Patch  n words  starting  at  a with 
octal  values  pi  thru  pn 
Same  as  above,  except  verify  patch 
with  a snap 


Insert  breakpoint  at  a 

Insert  breakpoint  at  a and  verify 

Delete  breakpoint  at  a 

Delete  breakpoint  at  a and  verify 


Transfer  control  to  a 
Transfer  control  to  a after  verifi- 
cat  ion 


If  at  a breakpoint,  reload  breakpoint  processor 
register  values  prior  to  transfer. 


Return  to  caller.  If  at  a breakpoint, 
resume  interrupted  execution  after 
reloading  processor  registers. 


Display  IC  where  dbug  was  called. 
This  is  useful  when  called  from 
other  than  a breakpoint. 


w{symbol}  Display  location  and  size  associated  with 
the  supplied  assembly  symbol,  provided 
the  symbol  was  assembled  into  the  sym- 
bol table. 
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Offset 


0 Display  current  offset  value 

Oc  Set  address  offset  to  c.  The  value  c 

will  be  added  to  all  dbug  verb  addresses 
if  they  are  not  designated  as  absolute. 


Verification 


VON 

Set  verification  mode  on 

VOFF 

Set  verification  mode  off 

VASIS 

Don't  change  verification  mode 

Processor  Register  Display 

X 

Display  all  processor  registers  in  XB,XP, 
XD  order 

XB 

Display  base  address  registers  in  XBA,XBB, 
XBE, XBR  order. 

SBA 

Display  MBA  contents.  If  a non-extended 
memory  processor,  so  indicate. 

XBB 

Display  MBB  contents 

XBE 

Display  BER  contents 

XBR 

Display  BAR  contents 

XP 

Display  'panel'  registers  in  XA,XQ,XE,XT, 
XI  order 

XA 

Display  AR  contents 

XQ 

Display  QR  contents 

XE 

Display  Exp-R  contents 

XT 

Display  timer  contents 

XI 

Display  all  index  registers  in  XO  to  X7 
order 

Xn 

Display  index  register  n 

XD 

Display  all  address  registers  in  XAO  to 
XA7  order 

XAn 

Display  address  register  n 

XIR 

display  indicator  register 

Processor  Register  Modification 

M(V}A  p 

Modify  AR  with  octal  value  p and  verify 
if  requested 

MlV}Q  p 

Same  as  above  except  for  QR 

M(V}E  p 

Same  as  above  except  for  ER 

MtV} IR  p 

Same  as  above  except  for  IR 

M 1 V } n p 

Same  as  above  except  for  index  register  n 

M i V }An  p 

Same  as  above  except  for  address  register 

n 
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For  all  modifications,  the  octal  value  P cannot  be 
larger  than  the  largest  value  that  can  be  contained  in 
the  register  to  be  modified, 

Absolute/Relative  Addresses 

All  dbug  addresses  are  treated  as  relative  to  the 
offset  (see  0)  unless  preceeded  with  the  letter  A, 
meaning  absolute. 

Finished 

F For  use  with  DBUG  in  a GELBAR  envir- 

onment, This  verb  effects  a DRL  to 
return  to  the  subsystem  or  program 
from  which  it  was  invoked. 


Line  Switch 

TPOS  has  a master  terminal  line  switch  capability. 
This  function  allows  the  line  to  be  switched  from  TPOS 
to  another  DAC  program  (such  as  time  sh;irinn) 
format  is: 

LSWIT  XXXXXX 

where  XXXXXX  is  the  name  of  the  DAC  program  to  which 
the  user  wishes  to  be  connected.  For  example,  to  switch 
from  TPOS  to  the  Time  Sharing  System,  one  would  type: 

LSWIT  TSS 

and  the  line  would  switch  to  the  TSS  logon  sequence. 


Terminal  ^old 

TPOS  has  a master  terminal  line  hold  capability. 
This  function  is  initiated  by  typing 

WAIT 

and  is  terminated  by  using  the  "break"  capability  on 
the  terminal  ($*$BRK  on  a CRT), 
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Termination 

TPOS  master  terminal  capabilities  may  be  exited 
via  the  "BYE"  command  which  will  cause  the  terminal  to 
be  disconnected  just  as  if  a logoff  had  been  performed 
from  the  Time  Sharing  System.  The  format  is: 

BYE 

Mast^  Terminal  Session 

The  following  three  pages  are  representative  of 
the  usage  of  the  master  terminal  functions. 
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SYSTEM  ?jdac  tpos 

**  TPOS:  U7/25/77  AT  22:4'<:10  ON  CHANNEL  405U 
PROGRAM  NAME?  stats 

ttnntnan 

REACT 

7TPOS 


TPOS  INTERNAL  STATUS  ON  07/25/77  FROM 


21:03:09  TO  22:49:31 


PROGRAM- 4 15 


SNUMB  0912T  ACTIVITY  02  URGENCY  05  SW  000000000000 


TIME 

START  20.762 
ASOF  22.826 
LAPSE  2.063 


PROCESSOR 

MEMORY 

I/O 

LINES 

USED 

0. 003308 

SWAP  7K 

USED  0.012 

USED 

78 

LIMIT 

GELBAR 

0.049623 

0.000222 

TOTAL  18K 

LIMIT 

LIMIT 

2048 

.ENDSP  - GELBAR  DISPATCHES  I53b 
.ENGI  - INTERRUPT  BROKEN  GELDARS  61 
.ENRLC  - RELINQUISHES  2285 
.ENRLT  - RESOURCE  LOCKUP  THRESHOLDS  0 
.ENTSS  - SCHEDULER  STALLS  0 
.ENLRT  - LOST  INTERCOM  BEADS  87 
.ENLWI  - LOST  INTERCOM  WRITES  0 
.ENRCV  - TRANSACTIONS  RECEIVED  38 
.ENMLA  - MAIN-LEVEL  CORE  ALLOCATIONS  0 
.ENMLS  - MAIN-LEVEL  SWAP  ALLOCATIONS  0 
.ENSAR  - MAIN-LEVEL  SWAP  REFUSALS  0 
.ENSWP  - SWAPS  0 
.ENNML  - NORMAL  TERMINATIONS  33 
.ENABT  - ABNORMAL  TERMINATIONS  5 
.ENIBO  - INPUT  BUFFER  OVERFLOWS  0 
.ENCRI  - INPUT  BUFFER  CORE  CHANGES  0 
.ENIOC  - COMPLETED  INPUT  OVERFLOWS  0 
.ENOBO  - OUTPUT  BUFFER  OVERFLOWS  0 
.ENCRO  - OUTPUT  BUFFER  CORE  CHANGES  0 
.ENOOC  - COMPLETED  OUTPUT  OVERFLOWS  0 


?Ut>TPOS  U 


TPOS  INTERNAL  STATUS  ON  07/25/77  FROM 


21:03:09  TO  22:50:38 


PROGRAM-*  15  SNUMB  8912T  ACTIVITY  02  URGENCY  05  SW  000000000000 


TIME 

PROCESSOR 

MEMORY 

I/O 

LINES 

START  20.762 

USED 

0.00337b 

SWAP  7K 

USED  0.012 

USED 

7b 

ASOF  22.844 
LAPSE  2.082 

LIMIT 

GELBAR 

0.049623 

0.000229 

TOTAL  18K 

LIMIT 

LIMIT 

204b 
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WHAT? 
?TPOS  C 


TPOS  INTERNAL  STATUS  ON  07/25/77  FROM  21:03:09  TO  22:51:17 


■ENDSP  - GELBAR  DISPATCHES  1574 
-ENGI  - INTERRUPT  BROKEN  GELBARS  61 
•ENRLC  - relinquishes  2329 
•ENRLT  - RESOURCE  LOCKUP  THRESHOLDS  0 
•ENTSS  - SCHEDULER  STALLS  0 
.ENLRT  - LOST  INTERCOM  READS  89 
•ENLWI  - LOST  INTERCOM  WRITES  0 
•ENRCV  - TRANSACTIONS  RECEIVED  38 
•ENMLA  - MAIN-LEVEL  CORE  ALLOCATIONS  0 
•ENMLS  - MAIN-LEVEL  SWAP  ALLOCATIONS  0 
•ENSAR  - MAIN-LEVEL  SWAP  REFUSALS  0 
•ENSWP  - SWAPS  0 
•ENNML  - NORMAL  TERMINATIONS  33 
•ENABT  - ABNORMAL  TERMINATIONS  5 
•ENIBO  - INPUT  BUFFER  OVERFLOWS  0 
•ENCRI  - INPUT  BUFFER  CORE  CHANGES  0 
.ENIOC  - COMPLETED  INPUT  OVERFLOWS  0 
•ENOBO  - OUTPUT  BUFFER  OVERFLOWS  0 
•ENCRO  - OUTPUT  BUFFER  CORE  CHANGES  0 
.ENOOC  - COMPLETED  OUTPUT  OVERFLOWS  0 
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1 

WHAT?  ] 

7TP0S  A 1 


TPOS  INTERNAL  STATUS  ON  07/25/77  FROM 


21:03:09  TO  22:52:34 


PROGRAM-!  15 


SNUMB  8912T  ACTIVITY  02  URGENCY  05  SW  000000000000 


TIME 

START  20.762 
ASOF  22.877 
LAPSE  2.115 


processor 

MEMORY 

I/O 

LINES 

USED 

0.003500 

SWAP  7K 

USED  0.014 

USED 

78 

LIMIT 

GELBAR 

0.049623 

0.000236 

TOTAL  18K 

LIMIT 

limit 

2048 

.ENDSP  - GELBAR  DISPATCHES  1600 
.ENGI  - INTERRUPT  BROKEN  GELBARS  62 
.ENRLO  - RELINQUISHES  2373 
.ENRLT  - RESOURCE  LOCKUP  THRESHOLDS  0 
.ENTSS  - SCHEDULER  STALLS  0 
.ENLRT  - LOST  INTERCOM  READS  90 
.ENLWI  - LOST  INTERCOM  WRITES  0 
.ENRCV  - TRANSACTIONS  RECEIVED  38 
.ENMLA  - MAIN-LEVEL  CORE  ALLOCATIONS  0 
.ENMLS  - MAIN-LEVEL  SWAP  ALLOCATIONS  0 
.ENSAR  - MAIN-LEVEL  SWAP  REFUSALS  0 
.ENSWP  - SWAPS  0 
.ENNML  - NORMAL  TERMINATIONS  33 
.ENABT  - ABNORMAL  TERMI .NATIONS  5 
.ENIEO  - INPUT  BUFFER  OVERFLOWS  0 
.ENCRI  - INPUT  BUFFER  CORE  CHANGES  0 
.ENIOC  - COMPLETED  INPUT  OVERFLOWS  0 
.ENOBO  - OUTPUT  BUFFER  OVERFLOWS  0 
.ENCRO  - OUTPUT  BUFFER  CORE  CHANGES  0 
.ENOOC  - COMPLETED  OUTPUT  OVERFLOWS  0 


?COME 

PROGRAM  NAME?  DBUG 

>tnni9f99)i 

<<<ENTER  DBUG 
DBUG?S) 

ERR  - ADDRESS  NOT  OCTAL 
DBL’G?S0 

OOOOOU  QOUOOQOOOUOO 
DBUG?F 

<<<EXIT  DBUG 


PROGRAM  NAME?  WAIT 
START  WAITING  ^ 22:54:52 
program  name?  LSWIT  TSS 

RADC  RiD  TSS  GCOS-GU3  07/25/77  AT  22.919  CHANNEL  4050 
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INSTALLATION  MACROS 

Several  macros  are  used  within  TPOS  to  tailor  it 
to  a particular  site's  operating  requirements.  Use  of 
the  macro  along  with  a description  of  the  macro 
parameters  follows. 


.TPOS . - Set  TPOS  Options 

This  macro  is  used  to  set  assembly  flags  that  control 
the  conditional  assembly  of  TPOS  modules  and  tailor 
TPOS  to  various  operating  environments.  The  macro  is 
used  as  follows: 

1 8 IS 

.TPOS.  [OPTIONS-STRING'l , . . . lOPTION-STRI NG-N ] 

Where  option  strings  currently  recognized  are: 

'SYMBOL-TABLE'  Sets  an  assembly  flag  so  macro 

.SYMT.  will  generate  a symbol  table. 

' CONSOLE=TTY ' Sets  an  assembly  flag  indicating 
that  a TTY  is  to  be  used  in  lieu 
of  a system  console. 

' SYMDEF-SYMBOL-TABLE-ENTRIES ' 

Sets  an  assembly  flag  indicating 
all  symbols  encountered  by  macro 
.SYMT.  should  be  SYMDEF'd. 

'REMOTE-I/0'  Sets  and  assembly  flag  to  allow 
conditional  assembly  of  Remote 
I/O  supervisor  code. 

The  .TPOS.  macro  call  should  be  inserted  immediately 
after  the  macro  definition.  See  the  assembly  listing. 


Intercom  Buffer  Space  Macro 
1 8 16 

. BUFF . Input-Intercom-Bu  ffer-Size, 

ETC  Output-Intercom-Buffer-Size 

This  macro  establishes  the  initial  sizes  of  the 
Intercom  input  and  output  buffers  in  words.  As  a 
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starting  point,  the  input  buffer  can  be  set  to  the 
average  message  size  times  the  number  of  TASKS  desired. 
Similarly,  the  output  buffer  size  can  be  set  to  the 
average  output  buffer  size  times  the  number  of  TASKs. 
If  memory  is  not  a problem,  the  maximum  memory  size 
should  be  substituted  for  the  average  message  size  in 
both  cases. 

This  macro  should  be  inserted  into  the  TPOS  assembly 
deck  as  specified  in  the  program  listing. 


Output  Intercom  Queue  Macro 
18  16 


.COMQ.  Number-of-Queue-Entr ’ es 

The  single  subfield  specifies  the  number  of  Output 
Intercom  Queue  entries  in  order  to  reserve  space  for 
the  complete  queue  at  assembly  time.  As  a guideline, 
the  number  of  queue  entries  should  be  at  least  as  large 
as  the  number  of  TASKs. 

This  macro  should  be  inserted  into  the  TPOS  assembly 
deck  as  specified  in  the  program  listing. 

Terminal  Control  Block  & Buffer  Space  Macro 
18  16 


.LINE.  Number-of-Terminal-Lines, 
ETC  Wait-f or-Reconnect-Time 


The  first  subfield  specifies  the  maximum  number  of 
terminal  lines  that  TPOS  is  to  handle. 


The  second  subfield  represents  the  time  interval  from 
terminal  disconnect  during  which  all  control 
information  is  to  be  held  in  limbo.  This  time  interval 
is  specified  in  seconds.  The  purpose  of  this  field  is 
to  allow  a reconnect  feature  in  a future  enhancement. 


This  macro  should  be 
deck  as  specified  in 


inserted  into  the  TPOS 
the  program  listing. 


assembly 
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Set  Maximum  Input  & Output  Message  Sizes  Macro 
18  16 


. MSG . Maxi mum- Input -Mess age-size , 

ETC  Maximum-Output-Message-Size 


Both  subfields  specify  the  message  sizes  in  words.  The 
maximum  input  and  output  message  sizes  should  be  chosen 
as  the  maximum  sizes  from  the  user-supplied  Keyword 
Processor  specifications. 


This  macro  should  be  inserted  into  the  TPOS  assembly 
deck  as  specified  in  the  program  listing. 


Swap-File  Map  Space  Macro 
18  16 


. SWAP.  Number-of-Swap-Map-Entr ies 


The  single  subfield  specifies  the  size  of  the 


in  terms  of  the  number 
than  255  entries  should 
TASK  remains  assigned 
swapped  and  the  maximum 


of  map  entries  desired, 
be  requested  since  an 
to  a program  even  wh 
number  of  TASKS  is  255. 


Swap-Map 
No  more 
in-core 
en  it  is 


The  .SWAP,  macro  can  be  omitted  if  a Swap-File  will  not 
be  allocated  to  TPOS.  This  macro  should  be  inserted 
into  the  TPOS  assembly  deck  as  specified  in  the  program 
listing. 


TASK  Space  Macro 
1 8 16 


. TASK . Number-of-TASKs ,TASK-Stack-Si ze 

The  first  subfield  specifies  the  maximum  number  of 
TASKS  which  are  to  be  assembled  into  TPOS.  No  more  than 
255  TASKS  can  be  requested. 


The  second  subfield  sets  the 
stack.  This  subfield  can  be 
TPOS  version. 

This  macro  should  be  inserted 


size 

of 

the 

TASK  IC&I 

left 

null 

for 

the  current 

into 

the 

TPOS  assembly 

J.  23 


SITE  REFERENCE 


deck  as  specified  in  the  program  listing. 
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SYMBOL  CONVENTIONS 


Certain  symbol  conventions  are  followed  within  the 
Executive  both  to  standardize  the  symbols  by  their 
generic  usage  and/or  content  and  to  avoid  confusion. 
The  conventions  are  currently: 


..xxxx  Explicitly  Named  Location  Counter  Symbol 
or  Location  Counter  Origin 

.xxxx.  Macro  Symbol 

.Axxxx  Assembly  Parameter  or  Symbol 

.AMRKn  MARK  Symbol  for  Conditional  Assembly 

.AMSWn  Switch  Symbol  for  Macro  Expansions 

.BITnn  General  Use  Bit  Symbol 

.BTxxx  TASK  or  TCB  Bit  Flag 

.Dxxxx  DRL  Processor  Primary  Entry  Point 

.Exxxx  Executive  Communication  Region  Cell 

.ENxxx  Executive  Accumulated  Count 

.Gxxxx  MME  Processor  Primary  Entry  Point  (for 
standard  GExxxx  MME  symbol) 

.Kxxxx  Keyword  Processor  Prefix  Area  Cell 

.KEYLn  Keywords  List  Offset  Symbol 

.PRFLn  Keyword  Processor  Profile  Offset  Symbol 

.Txxxx  TASK  Cell 

.TCxxx  Terminal  Control  Block  Offset  Symbol 
B.Txxx  TASK  Bit  Flag 

B.Axxx  Keyword  Processor  Attribute  Bit  Flag 
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DRLnnx 

or 

Dnnxxx 

MMEnnx 

or 

Mnnxxx 
YYY. nn 
YYYnnn 


Internal  DRL  Processor  Symbol 
(for  DRL  symbol  value  nn) 


Internal  MME  Processor  Symbol 
(for  MME  symbol  value  nn) 


Symbol  for  Entry  point  nn  of  Module  YYY 

Internal  Executive  Symbol  for  Module  YYY, 
Symbol  Sequence  Number  nnn 
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Explicitly  Named  Assembly  Location  Counters 


Named  location  counters  are  used  during  assembly 
to  order  or  position  coding  elements  and  data,  but  more 
importantly  to  allow  macro  definition  of  non-contiguous 
elements.  Current  location  counter  names  and  element 
description  are: 


..EXCR  Executive  Communication  Region 
. .XLIT  EIS  Transliteration  Tables 
..EXEC  Executive  Proper 
..MSG  Executive  Error  Messages 
. .PRFL  Keyword  Processor  Profiles 
. .KEYL  Keywords  List 
. .TASK  TASK  Space 

..LINE  Terminal  Control  Block  & Buffer  Space 
. .SYMT  Symbol  Table 

..BUFF  Input-Output  Buffer  sizes,  Output  Intercom 
Queue,  Swap-File  Map 


Location  counter  defined  assembly  elements  are 
sequenced  according  to  the  first  usage  order  of  the 
counters.  Notice  that  the  origin  of  each  explicit 
location  counter  must  be  properly  set  when  the  counter 
is  first  defined,  i.e.,  invoked. 


Executive  Module  Symbols 


Internal  Executive  symbols  for  its  modules  and 
their  component  routines  assume  the  form  YYYnnn,  where 
YYY  is  the  module  name  and  nnn  is  the  module  symbol 
sequence  number.  Current  module  YYY  names  are: 


AIO  Core  Allocator  I/O 
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CAL  Core  Allocator 

COM  Communication  Region 

DBG  Interactive  Dbug 

DRL  DRL  Validation/Handler 

DSP  Dispatcher 

ETX  Edit  Transaction  Number 

EXM  Executive  Message  Intercom 

FLT  Fault  Handler 

HKP  Housekeeping 

no  Intercom  I/O  Handler 

KEY  Message  Keyword  Processing 

MAC  Macros 

MAP  Map  Mechanics 

MME  MME  Validation/Handler 

RIO  Remote  I/O  Supervisor 

RLS  Remote  Line  Service 

SCH  Transaction  Scheduler 

STA  Inte f 1 VP  Statistics 

SYM  Symbols 

TRM  Terminator 

The  following  YYY  symbols  are  reserveo:  cMu,  DR 
DVC,  LUF,  MEM,  OFL,  ONC , PAR,  TAG,  TRO  and  ZOP . 
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Register  Convention 


The  only  dedicated  index  register  within  the 
Executive's  system  functions  is  XI.  This  is  used  to 
hold  a pointer  to  the  TASK  being  processed,  if 
appropriate  to  the  particular  function.  Though  the 
remaining  register  usage  is  not  specified,  generally 
the  lower  numbered  registers  are  treated  as  the  more 
volatile . 


Transfer  of  Control 


Transfer  of  control  among  the  system  functions  is 
currently  accomplished  via  the  .CALL.,  .EXIT.  and 
.GOTO,  macros.  See  transfer  of  control  chapter. 


There  is  transfer  of  control  register 
safe-storage  conventions  within  the  calling  sequence. 
If  safe-storage  is  necessary  it  must  be  done  by  the 
calling  routine.  As  an  aide  to  determining  which 
registers  are  affected,  each  routine  has  a preface  in 
the  assembly  listing  that  specifies  which  registers  i^ 
alters  or  destroys.  Notice  that  if  the  called  routine 
references  yet  another  routine,  it  is  necessary  to 
check  the  preface  of  the  latter  routine  too. 


Register  safe-storage  has  been  kept  to  a minimum 
wherever  possible  to  reduce  this  housekeeping  overhead. 
Extra  care  in  modifying  or  installing  a system  routine 
can  ensure  a minimum  of  register  interference  and 
necessary  safe-storage.  This  applies  particularly  to 
those  routines  which  are  executed  on  a frequent  basis. 


-Call  s 


Normally,  courtesy-calls  are  used  as  the  primary 
level  for  processing  with  the  main-level  suspended  in  a 
roadblocked  state.  Within  the  Executive,  cour tesy-cal Is 
are  used  as  a second  level  for  processing  in  addition 
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to  the  main-level.  Thus  the  main-level  is  not 
roadblocked.  The  Executive's  design  dictates  that  some 
functions  be  performed  and  their  component  routines  be 
given  control  at  both  the  main  and  courtesy-call 
levels . 


Inhibited  Code 


Inhibited  code  is  necessary  within  and  throughout 
several  system  functions.  Coding  must  be  so  conditioned 
when  a system  routine  is  'common'  to  both  main  and 
courtesy-call  levels  and  not  reentrant  or  when  it 
references  or  modifies  data  that  is  'common'  to  both 
main  and  courtesy-call  levels. 


Non-reentrant  system  routines  are  inhibited  in 
order  to  ensure  that  they  are  not  busy  when  called  by 
an  interrupting  courtesy-call.  Determination  of  whether 
or  not  a routine  is  inhibited  must  be  made  by  examining 
the  assembly  listing. 


Data  that  must  be  handled  with  inhibited  code  is 
generally  a system  queue  or  map.  Inhibiting  the 
main-level  data  reference  functions  similarly  to  a 
programmed  gate  by  eliminating  overlaping  references 
and  the  confusion  they  could  create.  Notice  that 
inhibiting  is  only  requited  at  the  main-level  since  a 
courtesy-call  cannot  be  interrupted  by  either  the 
main-level  or  by  another  courtesy-call. 


The  need  for  an  inhibited  reference  in  any 
particular  case  depends  on  the  type  of  access  intended. 
For  example,  inhibiting  would  not  be  necessary  if  the 
reference  is  meant  to  'just  take  a look';  however,  if 
the  reference  is  meant  to  modify  or  to  check  for  some 
condition  and  temporarily  preserve  it,  inhibiting  would 
be  required.  To  aide  in  determining  which  items  are 
susceptible  to  this  problem,  the  item  descriptions  are 
keyed  according  to  whether  or  not  cour tesy-ca 1 1 
reference  is  made  to  them. 
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TASK  Symbol  Usage 


TASK  symbols  are  relative  offset  symbols; 
consequently  their  difference  is  absolute.  When  using 
these  symbols  and  referencing  one  TASK  cell  given  a 
pointer  to  another  (other  than  the  base  of  the  TASK)  , 
the  pointer  offset  should  be  expressed  as  a symbolic 
difference  rather  than  a numeric  difference.  If  this  is 
not  done  and  TASK  symbols  are  reshuffled,  deleted, 
etc.,  the  pointer  offset  will  be  in  error.  TASK  format 
flexibility  is  the  primary  benefit  derived  from 
symbolic  definition. 


Fault  Requested  System  Services 


Keyword  Processors  can  request  system  services  by 
generating  a processor  fault  with  the  MME  or  DRL 
instructions.  Currently  only  a subset  of  the  standard 
GCOS  MME  functions  are  supported.  For  a description  of 
the  interface  between  the  Executive  and  this  type  of 
system  service,  see  the  MME  processor  section.  For  a 
description  of  the  restrictions  and  conventions  to  be 
observed  by  the  service  routines  themselves,  see  the 
Dispatcher's  Queue  discussion. 
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TRANSFER  OF  CONTROL 


Transfer  of  control  in  the  initial  version  of  TPOS  was 
accomplished  via  TSXn  type  instructions.  As  development 
continued,  this  method  failed  to  provide  the 
flexibility  required  by  new  functions.  Two  types  of  IC 
& I stacks  were  incorporated  to  eliminate  most  transfer 
of  control  difficulties. 


IC  & I Stacks 


The  first  stack  is  a master  or  TPOS  stack,  located  at 
.ESTAK.  The  stack  pointer  is  located  in  .EICIS  as  a 
tally  word.  This  stack  pointer  always  points  to  the 
last  entry  node  in  the  stack  provided  the  stack  isn't 
empty. 

The  other  type  of  stack  is  the  TASK  stack,  located  at 
offset  symbol  .TSTAK  in  each  TASK.  The  stack  pointer  is 
located  at  offset  symbol  .TALLY  of  the  stack.  As  with 
TPOS's  stack,  the  stack  pointer  always  points  to  the 
last  entry  mode  in  the  stack. 

With  both  stacks,  reference  to  the  last  entry  mode  is 
accomplished  by  using  the  tally  stack  pointer  word  as 
an  indirect  word. 


TRANSFER  OF  CONTROL 


There  are  three  allowable  transfers  of  control 
mechanism.  They  are  the  .CALL.,  .EXIT.,  and  .GOTO, 
macros.  The  latter  never  involves  a stack. 


.CALL.  Mechanism 


The  .CALL,  macro  is  used  for  making  an  entry  in  the 
appropriate  IC&I  stack,  if  one  is  specified,  and  then 
transferring  control  to  the  desired  location.  The  macro 
expansion  and  method  for  making  a stack  entry  varies 
according  to  the  stack  to  be  used. 

For  TPOS's  stack,  the  macro  expands  into: 
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1 8 16 


XED  .EPUSH 

DRL  (transfer  location) 

Where  .EPUSH  is  a fixed  instruction  pair  consisting  of; 
18  16 


EVEN 

.EPUSH  STCl  .EICIS,DI 

TTF  1,IC* 


For  a TASK  stack  ,X7  must  point  to  the  applicable  TASK. 
In  this  case  the  macro  expands  into: 


1 

8 

16 

XED 

DRL 

. ECALL 

(transfer  location) 

Wher  e 

. ECALL 

is  a fixed  instruction  pair  consisting  of: 

1 

8 

16 

.ECALL 

EVEN 

STCl 

TTF 

.TPUSH, ?* 
1 , TC* 

and  .TPUSH  is 
making  a TASK 

a NOP  within  the  applicable  TASK  used  for 
stack  entry.  This  call  consists  of: 

1 

8 

_16_  

.TPUSH 

NOP 

.TALLY ,DI 

.TPUSH  is  a necessary  part  of  this  sequence  since  it 
holds  the  absolute  address  of  .TALLY,?  (relative  to 
TPOS's  LAL)  thereby  making  it's  address  modification 
field  available  for  the  DI  type  tally  modification.  If 
the  TASK  is  moved,  .TPUSH  must  be  adjusted  to  reflect 
the  new  location  of  .TALLY,?. 

Overflow  protection  exists  for  either  stack.  If  a stack 
overflow  occurs,  the  TTF  transfer  at  .EPUSH  or  .ECALL+1 
will  not  be  taken.  This  causes  the  DRL  in  either  macro 
expansion  to  be  executed.  There  is  no  confusion  between 
a stack  overflow  DRL  and  a service  DRL,  since  the 
latter  is  returned  through  the  GELBAR  Fault  Vector 
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instead  of  the  DRL  Fault  Vector  in  TPOS's  SPP. 


.CALL.  USAGE 


The  .CALL,  macro  is  used  as  follows: 
18  16 


.CALL  I Symbol,  Null  1 

{ i,  Call-Mode- 

Designator 

I Module-Name , Entry-PointI 

the  Call-Mode-Designator  specifies  the  type  of 
to  be  made  and  consequently  affects  the  inline 
expansion,  Call-Mode-Designators  are: 

or  T Use  IC&I  stack  in  TASK  pointed  to  by  X7. 

Use  TPOS's  IC&I  stack. 

DO  not  use  any  stack.  Instead  generate 
a TSXn  to  the  specified  symbol  or 
module-name,  entry  point. 

The  last  Call-Mode-Designator  was  included  to  allow 
existing  TSXn  transfer  of  control  calls  to  be  inverted 
to  the  .CALL,  format.  This  designator  is  not  intended 
for  future  use  except  when  calling  a module  which  does 
not  use  a stack  to  exit. 


.EXIT.  Mechanism 

The  .EXIT,  macro  is  used  for  removing  an  entry  from  the 
appropriate  IC&I  stack,  if  any,  and  then  returning 
control  to  that  IC  plus  a variable  offset.  As  with  the 
.CALL,  macro,  the  macro  expansion  varies  according  to 
the  stack  specified  in  the  macro  call. 

FOR  TPOS's  stack,  the  macro  expands  into: 

18  16 


EAXO  (var iable-of f set) +1 

XED  .EPOP 


Where 
cal  1 
macro 

Blank 

E 

Xn 
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Where  .EPOP  is  a fixed  instruction  pair  consisting  of: 

1 8 ^ 

EVEN 

.EPOP  ASXO  .EICIS,I 

RET  .EICIS,ID 

The  first  expansion  instruction  sets  XO  to  the 
specified  offset  from  the  .CALL,  plus  one  to  step  the 
calling  IC  past  the  DRL  in  the  .CALL,  macro  expansion. 
The  two  instructions  at  .EPOP  add  the  desired  IC  offset 
to  the  IC  within  the  stack  and  then  return  control  to 
the  resulting  IC  as  the  stack  pointer  is  popped  to  the 
previous  stack  entry. 

For  a TASK  stack,  X7  must  point  to  the  applicable  TASK. 
In  this  case,  the  macro  expands  into: 

1 8 16 

EAXO  (variable-off set ) +1 

XED  .EEXIT 

Where  .EEXIT  is  a fixed  instruction  pair  consisting  of: 

1 8 16_ 

EVEN 

.EEXIT  ASXO  .TALLY,?* 

RET  .TP0P,7* 

This  mechanism  is  the  equivalent  of  the  TPOS  stack  exit 
mechanism  except  an  indirect  word  at  .TPOP,7  in  the 
TASK  is  required  to  effect  the  ID  tally  modification 
for  popping  the  stack.  The  contents  of  .TPOP  are; 

1 8 16 

.TPOP  NOP  .TALLY, ID 


.EXIT,  Usage 

The  .EXIT,  macro  is  used  as  follows: 

1 8 16  

.EXIT.  IC-Offset,  Ca 1 1 -Mode-Des i gnator , 
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Condi tional-Transfer 


The  IC-offset  represents  the  number  of  instructions  to 
be  shipped  past  the  .CALL.  calling  sequence.  The 
Call-Mode-Designator  tailors  the  macro  expansion  as 
follows : 


Null  or  T 


E 

N,Xn, *Xn, 
AU,AL,QU,QL, 
*AU,*AL,*QU,*QL, 
I 


If  the  third  parameter  is  not  null, 
the  two  instructions 

Conditional-Transfer  2,IC 
TRA  3,IC 

are  generated  to  allow  a 
conditional  exit.  These 

instructions  are  immediately 

followed  by  the  expansion  which 
returns,  using  the  IC&I  in  TASK 
stack . 

Return  using  IC&I  in  TPOS's  stack. 

If  the  third  subfield  is  null,  the 
single  instruction 

TRA  IC-offset,  Register-Modification 
implied  by  Call-Mode- 
Designator 

is  generated. 


If  the  third  subfield  is  not  null,  the 
single  instruction. 


Conditional-Transfer  IC-Offset,  Reg- 
ister Modifica- 
tion implied  by 
Call-Designator 


As  with  the  .CALL,  macro,  .EXIT.  Ca 1 l-Mode-Des igna tor s 
other  than  Null,  T or  E were  included  for  comparability 
with  existing  procedures.  These  designators  should  be 
avoided  in  new  procedures. 
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•GOTO.  Usage 


The  .GOTO,  transfer  of  control  macro  is  used  as 
f ol  lows : 

18  16 


.GOTO.  [Symbol,  Address-Modification] 

{ } 

I Module-name , Entry-Point  I 


Condition- 

al-Transfer 


The  Module-name,  Entry-Point  option  will  generate: 

I TRA  I [Symbol,  Address-Modification] 
{ or  } { or  } 
[Conditional-Transfer  [ [Module-Name,  Entry-Point  [ 


Where  allowable  address  modification  types  are: 
N,Xn,I ,AU,AL,QU,QL,*Xn, *AU, *AL,*QU, *QL 


Precaution 

Both  .CALL,  and  .EXIT,  macro  expansions  can  consist  of 
more  than  one  instruction.  As  a result,  care  must  be 
taken  when  calling  modules  with  multiple  returns  since 
a .CALL,  followed  by  another  .CALL,  or  a .EXIT.  could 
result  in  a return  to  an  instruction  interior  to  an 
expansion . 
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EXECUTIVE  COMMUNICATION  REGION 


This  region  of  the  Executive 
storage  and  for  communication 
internal  functions.  As  such,  the 
following : 


is  used  for  common 
among  the  Executive's 
region  contains  the 


assembled  constants 


that 


define 


the 


Executive's  parametric  structure 


o status  of  internal  Executive  functions 


o control  information  for  internal  functions. 


Symbolic  tags  for  Communication  Region  cells  are  of  the 
general  form  .Exxxx. 


Special  Usage 


Some  Communication  Region  cells  are  referenced 
within  both  main  and  courtesy-call  level  processing. 
These  cells  must  be  handled  with  extra  care  as  dictated 
by  the  type  of  reference  being  made.  In  order  to 
identify  these  cells  it  is  sufficient  to  indicate  which 
ones  are  accessed  in  the  courtesy-call  routines.  This 
is  done  by  inserting  the  key  (CC-Fef)  after  the  cell 
name  in  the  following  communication  cell  descriptions. 
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. EACQS  - Allocator's  Core-Queue  Service  (CC-Ref) 


0  25  26 

I PTR  TO  .TMEM  OF  LAST  TASK  I NO-PASS  TALLY  iMBZ 

1 UNSUCCESSFULLY  SERVICED  BY  lor  SELECTION  I 

I MAIN-LEVEL  CORE  ALLOCATOR  I Q-DEPTH  I 


The  upper  half  of  this  cell  holds  the  current  service 
position  within  the  Core-Queue.  This  position  can  point 
to  the  base  of  Core-Queue  when  the  next  queue-entry 
eligible  for  selection  is  the  first  entry  in  the  queue. 
The  lower  half  of  this  cell  holds  a demand  selection 
Core-Queue  depth  tally  that  indicates  the  number  of 
TASKS  remaining  to  be  serviced  up  to  and  including  the 
highest  priority  no-pass,  when  positive,  and  indicates 
the  current  Core-Queue  depth  of  the  service,  when 
negative.  This  cell  is  used  to  interlace  courtesy-call 
and  main-level  allocation  activities. 


.EAIXP 

(CC-Ref) 


Allocator's  Interrupted  Execution  Phase 


[NEGATIVE  COUNT  OF  COURTESY- 
CALL  NO-PASS 's 


17  18 

I main-level’  execution 

I PHASE 


The  upper  half  of  this  word  holds  a negative  count  of 
Core-Queue  no-pass's  that  were  linked  or  forced  in 
courtesy-call.  The  lower  half  describes  the  current 
phase  of  the  main-level  allocator  as  follows: 


0 = not  enabled 


1 = demand  (load)  allocation 

2 = 'swap'  resourct  allocation. 


This  cell  IS  used  by  courtesy-call  routines  to 
interlace  their  functions  with  main-level  allocations 
functions . 
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.EBAS5  - Base  Address  Setting 


0 

17 

18 

29  30 

35 

1 BASE 

ADDRESS 

SETTING 

INOT  USED 

|X5  MOD 

1 

This  word  is  used  to  resolve  an  address  given  an  offset 
in  index  register  5 (X5)  to  the  base  setting  in  the 
upper  half  of  this  word.  The  base  setting  is  the  LAL  of 
some  Keyword  Processor.  This  cell  is  set  by  the 
Dispatcher  at  every  dispatch. 

.ECALL  - Make 

Entry  in  TASK 

IC&I  Stack 

0 

17 

18 

35 

1 STCl 

1 .TPUSH, 7* 

1 

1 TTF 

11, IC* 

1 

.ECMAP  - Core- 

Map  (CC-Ref) 

0 

17 

18  25 

26  27 

35 

1 FWD 
1 

CORE-MAP 

PTR  (.TMEM) 

1#  FREE  1024  10  |MBZ 
IWORD  BLOCKS  | I 

1 

1 

1 MBZ 

1 SWAP-CORE  LAL 

1 

IMBZ  1 

Tbkwd 

CORE-MAP 

PTR  (.TLAL) 

1 SWAP-CORE  UAL 

Four  words  representing  the  base  Core-Map  entries.  The 
first  two  words  are  the  first  Core-Map  entry  and  the 
last  two  words  are  the  last  map  entry.  Base  entry 
format  is  identical  to  the  general  Core-Map  entry.  (See 
Core/Swap  Map  discussion) . Swap-core  is  the  core  area 
in  which  Keyword  Processors  are  loaded  and  executed. 
The  swap-core  UAL  is  defined  to  be: 


(swap-core  LAL)  + (swap-core  size) 


in  multiples  of  1024-word  blocks.  At  assembly  time 
.ECMAP  upper  points  to  .ECMAP+2,  and  .ECMAP+3  upper 
points  to  .ECMAP+1. 


.FCNSL  - CONSOLE  ID 

23  24  35 

rTEHMINAL"in  I 


0 

1 MBZ 
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One  word  that  holds  the  Terminal  Identification  when  a 
TTY  is  used  in  lieu  of  a system  console. 

.ECOMO  - Output  Intercom  Enabled  Flag  (CC-Ref) 


This  flag  is  used  to  indicate  that  Output  Intercom  I/O 
is  enabled  and  that  the  cou r tesy-ca 1 1 Output  Intercom 
routine  is  executing,  when  set  to  a non-zero  value.  The 
flag  is  controlled  by  the  Output  Intercom  I/O  routines. 


. ECOMQ  - Output  Intercom-Queue  Space  (CC-Ref) 

0_  17  18  35 

IPTR  TO  LAST  ASSIGNED  OUTPUT'TpTR ‘tO  FIRST  FREE  OUTPUTi 

l_INTERCOM-Q  JNTRY  SPACE+1 il NTERCOM-Q_ENTRY_pr  _Z E^J_ 

V(.ECQSZ)  ^ '''  ” I ~ ' I 

I INTERCOM-Q  ENTRY  SPACE+1 | INTERCOM-Q  ENTRY  or  ZEROl 

These  cells  are  used  to  manage  the  free  Output 
Intercom-Queue  entries  as  an  available  chain.  The  words 
are  defined  by  the  Output  Intercom-Queue  macro 

(.COMQ.).  .ECOMQ  upper  is  assembled  to  point  to  the 
first  word  past  the  assigned  space  and  the  lower  half 
is  assembled  as  the  location  of  the  first  assigned 
queue-entry.  ECQSZ  lower  holds  a bit  mask  used  to 
allow/disallow  Intercom-Queue  entry  requests  within  the 
Dispatcher ' s-Queue  Service.  To  allow  requests,  the  mask 
is  'ORed'  into  .EDQSM,  while  to  ignore  requests,  the 
1 ' s-complement  of  the  mask  is  'ANDed'  with  .EDQSM.  The 
mask  bit  position  is  assigned  symbolically  in 

accordance  with  the  bit  position  of  the  'Need  Output 
Intercom-Queue  Entry'  TASK  Status  Flag  (B.TNQE). 


. ECQP  - Output  Intercom-Queue  (CC-Ref) 

0 17  18  35 

IFWD  LINKED  OUTPUT  INTERCOM-*  IBKWD  LINKED  OUTPUT  lNTEHCOM-1 
] QUEUE  ENTRY  PTR  or  ZERO [QUEUE  ENTRY  PTR  or  ZERO I 

This  cell  holds  the  forward  and  backward  pointers  to 
rhe  head  and  tail  of  ttie  Ourput  l ntercom-Queue . Entries 
linked  to  the  queue  are  waiting  or  in  transmission. 
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. ECORQ  - Core-Queue  (CC-Ref) 

P 17  18 25  26 35 

IFWD  CORE-QUEUE  ENTRY  PTR  I BKWD  CORE-QUEUE  ENTRY  PTRl 

ITO  .TMEM  or  ZERO | TO  .TLAL  or  Z E RO I 

I#  OF  TASKS  LINKED  TO  CORE-QUEUE  ImBZ  T 


Two  words,  the  first  of  which  holds  the  link  pointers 
to  the  first  and  last  entries  in  the  Core-Queue  and  the 
second  contains  a count  of  the  number  of  TASKS  linked 
to  the  queue. 


.ECQSZ  - Output  Intercom-Queue  Entry  Size 


The  upper  half  of  this  cell  is  set  during  assembly  to 
the  Output  Intercom-Queue  entry  size  by  the  .COMQ.  This 
cell  must  be  paired  with  cell  .ECOMQ.  (See  .ECOMQ). 


.EDAMP  - Static  Core  Allocator  Dampers  (CC-Ref) 

P 

I STATIC  CORE-MAP  DAMPER 
IfTATIC  SWAP  _DAMPER 


The  Static  Co 
control  that, 
to  the  curre 
Swap  Damper  is 
control  that, 
to  the  set  of 
swap-e 1 igible 
core.  The  damp 
value.  (See  Co 


re-Map  Damper  is  a Core-Queue  to  Core-Map 
when  on,  signifies  core  is  full  relative 
nt  demands  in  the  Cote-Queue.  The  Static 
a Core-Queue  to  'swapable*  cote-holes 
when  on,  signifies  core  is  full  relative 
core-holes  that  would  be  created  if 
Keyword  Processors  were  swapped-out  of 
ecs  are  on  when  they  assume  a non-zero 
re  Allocator  discussion). 


.EDQSM  - Dispatcher ' s-Queue  Service  Mask 

0 17  18  35 

IMBZ*  I DISPATCHER' S-QUEUE  I 

1 I SERVICE  BIT  MASK  I 


This  cell  is  used  by  the  Di spa tcher ’ s-Queue  Service 
when  scanning  the  status  of  TASKs  linked  to  the  queue 
in  order  to  determine  if  a TASK  is  roadblocked  by  or 
requesting  some  Executive  function.  Selected  bits 
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within  the  mask  are  set  off  by  the  applicable  service 
routines  when  their  service  cannot  be  provided.  The 
bits  are  set  on  when  a service  request  is  possible.  Of 
the  bits  used  in  the  mask,  the  bit  positions  are 
aligned  with  the  like  bit  positions  symbolically 
assigned  to  those  TASK  Status  Flags  being  scanned. 


.EDQSP  - Dispatcher ' s-Queue  Service  Position  (CC-Ref) 

0 17  18  _ __  35 

IPTR  TO  .TFLAG  OF  NEXT  TASK  I'SERVICE  IN  PROGRESS  FLAG  I 

1 TO  SERVICE  I I 


This  cell  holds  the  location  of  the  next  TASK  to  be 
serviced  by  the  Dispatcher ' s-Queue  Service  in  the  upper 
half,  and  a flag  that  indicates  the  queue  service  is 
enabled,  when  non-zero,  in  the  lower  half. 


.EDSPQ  - Dispatcher ' s-Queue  (CC-Ref) 

___  ^ 

lEWD  DSP-Q  ENTRY  >TR'‘  I BKWD 'dSP'-Q  ENTRY  PTR 

|TO_.TPRiq_^_ZERO_  I TO  .TFLAG  or  ZERO 

I#  OF'tASKs  LINKED  TO  DSP-Q 


Two  words,  the  first  of  which  holds  the  link  pointers 
to  the  first  and  last  entries  in  the 
Dispatcher ' s-Queue , and  the  second  contains  a count  of 
the  number  of  TASKs  which  are  linked  to  the  queue. 


.EEXIT.  - Remove  Entry  from  TASK  IC&I  Stack 
0 17  18  35 


1 ASXO 

(.TALLY, 7*  1 

1 RET 

T .fPOP, 7*  _ _~T 

Two  words  that  hold  the  fixed  instruction  pair  used  by 
the  .EXIT,  macro  to  add  a return  offset  to  the  calling 
1C  in  the  TASK  stack  and  to  logically  remove  the  entry 
from  the  stack  while  returning  control  to  the  resulting 
IC.  See  transfer  of  control. 
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•EGTQS  - GELBAR  Time  Quantum  Sum 

0 35 

I GELBAR  TIME  QUANTUM  SUM  FOR  ALL  GELBAR 'd  PROCESSOR  TIME  I 

This  cell  is  used  to  accumulate  all  processor  time  used 
by  the  Keyword  Processors  themselves. 

•EIMAP  - Input  Intercom  Buffer  Map  (CC-Ref) 


0 17  18  35 


IFWD  INPUT  BUFFER  MAP  PTR 
1 

1 # OF  UNATTACHED  WORDS  AT  1 
ITHE  START  OF  THE  BUFFER  1 

TlOC  of  last  INPUT  BUFFER 
ICELL 

T^ESERVED  ~1 

1 1 

Two  words,  the  first  of  which  holds  the  Input  Intercom 
Buffer  base  map  entry.  The  second  word  is  used  to 
record  the  last  buffer  cell  address  and  is  not  required 
by  map  mechanics.  These  words  are  defined  by  the 
Generate  Buffer  Space  macro  (.BUFF.).  See  Buffer  Map 
discussion  for  a further  explanation. 

I 

.EINCC  - In  Courtesy-Call  Flag 

This  cell  is  used  by  internal  routines  that  execute  at 
both  main  and  courtesy-call  levels  to  indicate  that 
execution  is  at  the  courtesy-call  level. 

.EINIT  - Initialization  Vector 


.EINIT  IS  the  primary  SYMDEF  entry  point  to  the 
Executive.  This  cell  holds  a startup  vector  to  the 
Executive's  Initialization  Routine.  The  transfer  is 
required  because  the  initialization  routine  is  attached 
to  the  Executive  as  a link,  consequently  the  entry 
SYMDEF  must  be  to  the  main  link. 


.EKEYL  - Keywords  List  (CC-Ref) 


0 17  18__ 25  26 35 

TpTR  to  FIRST  KEYWORD  ‘ f # KEYWORDSrMBZ  ' T 
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This  cell  is  built  during  assembly  and  is  used  by  those 
routines  that  search  the  Keywords  List.  The  cell  is 
defined  during  assembly  after  all  profiles  and  keyword 
entries  have  been  built. 


.ELDSP  - Last  Dispatch 

0  LZ_18 35 

1 LOC  OF  ' LAST  DISPATCHED  TASK  I NOT  USED j_ 

This  word  holds  a pointer  to  the  last  TASK  that  was 
dispatched  to.  This  cell  is  set  by  the  Dispatcher  and 
used  by  the  Fault  Handler. 


.EMXSZ  - Maximum  Message  Size 

0 _ __  35 

IMAXIMUM  OUTPUT  MESSAGE  SIZE i MAXIMUM" INPUT  MESSAGE  SIZE) 

One  word  that  holds  the  maximum  output  message  size  and 
the  maximum  input  message  size  as  declared  to  TPE  in 
the  Executive's  Profile.  This  word  is  used  to  screen 
Keyword  Processor  Profiles  during  startup,  to  allocate 
input  buffer  space  and  to  ensure  that  output  messages 
do  not  exceed  the  maximum  output  message  size  declared 
to  TPE.  This  cell  is  defined  during  assembly  by  the 
.MSG.  macro. 


.ENPQD  - No-pass  Q-Depth  (CC-Ref) 

0__  17  18 25  26 35 

IPTR'tO  .TPRIO  OF  HIGHEST  ' TnO-PASS  I MBZ  I 

I PRIORITY  NO-PASS  TASK  iQ-DEPTH  I _ 1 


The  upper  half  of  this  cell  holds  a pointer  to  TASK 
cell  .TPRIO  of  the  highest  priority  no-pass  in  the 
Core-Queue  and  the  lower  half  holds  the  Core-Queue 
depth  of  the  no-pass . If  a no-pass  does  not  exit,  this 
cell  is  zero. 


.ENUQD  - Selection  Q-Depth  (CC-Ref) 

0 J_7  18_  __  25  26  35 

IMBZ  - - ■ ISRLECTION  '|MOZ~  “I 

1 I Q-DEPTH  I 1 
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This  cell  holds  the  Core-Queue 
unsuccessfully  serviced  by 
Allocator  during  demand  (load) 
can  be  zero  when 
is  the  first  TASK 


depth  of  the  last  TASK 
the  main-level  Core 
allocation.  The  Q-depth 
the  next  TASK  eligible  to  be  selected 
in  the  Core-Queue.  This  cell  is  used 


by  courtesy-call  routines  to  help  determine  the 
allocation  eligibility  of  a newly  linked  demand  and  to 
interlace  courtesy-call  and  main-level  functions. 


.EOMAP  - Output  Intercom  Buffer  Map  (CC-Ref) 


0 

17 

18  35 

IFWD  OUTPUT 
1 

BUFFER  MAP  PTR  1 
1 

# OF  UNATTACHED  WORDS  AT  1 
THE  START  OF  THE  BUFFER  1 

1 LOC  OF  LAST 
1 CELL 

OUTPUT  BUFFER  I 
1 

RESERVED  1 

1 

Two  words,  the  first  of  which  holds  the  Output  Intercom 
Buffer  base  map  entry.  The  second  word  is  used  to 
record  the  last  assigned  buffer  cell  address  and  is  not 
requited  by  map  mechanics.  These  words  are  defined  by 
the  Generate  Buffer  Space  macro  (.BUFF.).  See  Buffer 
Map  discussion  for  a further  explanation. 


.EORG  - TPOS  Origin 

This  symbol  under  location  counter  ..EXCR  locates  the 
origin  of  TPOS. 


. EPOP  - Remove  Entry  from  TPOS's  IC&I  Stack 
0 17  18  35 

Tasx  0 ^ ZLe  I C I S J ZH 

IRET  I.EIC'fs,ID  ] 


Two  words  that  hold  the  fixed  instruction  pair  used  by 
the  .EXIT,  macro  to  add  a return  offset  to  the  calling 
IC  in  TPOS's  TASK  Stack  and  to  logically  remove  the 
entry  from  the  stack  while  returning  control  to  the 
resulting  IC.  See  transfer  of  control. 
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.EPRFL  - Keyword  Processor  Profiles 

0  17  18 25  26 ^ 

IPTR  TO  FIRST  KEYWORD  I#  OF  IMBZ  I 

1 PROCESSOR  PROFILE  I PROFILES  I I 


This  cell  points  to  the  first  Keyword  Processor  Profile 
in  the  upper  half  and  holds  the  number  of  profiles 
assembled  in  the  lower  half.  This  number  is  scaled  for 
use  as  the  tally  of  a Repeat  instruction. 


•EPRFX  - Keyword  Processor  Prefix 


This  symbol  is  used  to  symbolically  define  the  size  of 
the  Keyword  Processor  Prefix  Area,  that  is  the  equated 
value  of  the  symbol  is  the  prefix  size.  There  is 
storage  associated  with  this  symbol. 


.EPUSH  - Make  Entry  in  TPOS  IC&I  Stack 


0 

17  18 

35 

1 STCl 

1 . EICIS, DI 

1 

ITTF 

1 1,IC* 

1 

Two  words  that  hold  the  fixed  instruction 
the  .CALL,  macro  to  make  an  IC&I  entry  in 
This  stack  is  located  at  . ESTAK  and  the 
is  a tally  word  at  .EICIS.  See  transfer  of 

pair  used  by 
TPOS ' s stack, 
stack  pointer 
control . 

.EQMIN  - Core-Queue/Core-Map  Fence 

(CC-Ref ) 

0 

17  18 

35 

1 MBZ 

ICORE-Q 

: : CORE-MAP  FENCE 

1 

This  cell 
functions 
Core-Queue 

is  an  internal  Core  Allocator  control 
as  a fence  between  the  demands  in 
and  the  available  core-holes  in 

that 

the 

the 

Core-Map.  Whenever  the  Static  Core-Map  Damper  is  on, 
the  following  relationship  is  satisfied: 

max  Core-Map  (available  core-hole)£  .EQMIN  < min 
Core-Queue  (resource  demands) 

See  the  Core  Allocator  discussion  for  a further 


7.10 


1 

COMMUNICATION  REGION 
explanation. 

. ERLUF  - Resources  Lock-Up  Flag 


This  is  a one  word  flag  that  is  on  when  it  holds  a 
non-zero  value.  The  flag  is  set  on  by  the  Dispatcher 
when: 

(1)  the  Dispatcher ‘ s-Queue  is  not  empty 

(2)  it  is  unable  to  select  a TASK  eligible  for  dispatch 

(3)  the  Output  intercom  Processor  is  not  active 

(4)  no  TASKS  are  roadblocked  by  outstanding  device  I/O. 


If  the  Dispatcher  cannot  clear  the  flag  after  one  queue 

service  attempt,  it  initiates  lockup  threshold  logic  | 
and  commences  aborting  TASKS  to  free-up  resources.  In  ! 
the  event  the  lockup  remains,  the  Dispatcher  will  abort  j 
the  Executive.  | 


.ESDAT  - Startup  Date 


I STARTUP  DATE  (MMDDYY) 


One  word  that  holds  the  startup  date  at  the  completion 
of  initialization. 


.ESDQP  - Swap  Search  Dispatcher ' s-Queue  Position 
(CC-Ref ) 

0 17  18 35 

IPTR  TO  .TPRIO  OF  NEXT  TASK  I MBZ  I 
IWHERE  SWAP-ELIGIBLE  TASK  I I 
] SEARCH  IS  TO^RESUME [ 

This  cell  is  used  du'ing  main-level  swap  resource 
allocation  to  hold  a pointer  to  cell  .TPRIO  of  the  next 
TASK  where  the  swap-eligible  TASK  search  is  to  resume. 
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•ESMAC  - Swap-File  Map  Space  (CC-Ref) 


i 

1 

1 

1 

1 

1 

1 

18 

35 

1 PTR  TO  LAST  ASSIGNED  SWAP- 1 
IFILE  MAP  ENTRY  SPACE+1  1 

PTR 

MAP 

TO  FIRST 
ENTRY  or 

FREE  SWAP-FILE  1 
ZERO  1 

1 SWAP-FILE  MAP  ENTRY  SIZE  1 
1 1 

MBZ 

T 

1 

Two  words  used  to  build 

or 

release 

Swap-File  Map 

encries.  The  lower  half  of  the  first  word  points  to  the 
first  available  map  entry  if  there  is  one.  These  cells 
are  defined  by  the  Generate  Swap-File  Map  space  macro 
(.SWAP.).  .ESMAC  upper  is  assembled  to  point  to  the 
first  word  past  the  assigned  space  and  .ESMAC  lower  is 
assembled  to  point  to  the  first  assigned  Swap-File  Map 
entry . 


. ESMAP  - Swap-File  Map  (CC-Ref) 


0 

17 

18 

35 

1 FWD 

SWAP-FILE  MAP 

PTR 

1 # OF  FREE 

64  WORD 

BLOCKS  1 

1 MRZ 

1 SWAP-FILE 

LAL 

1 

1 MBZ 

1 

1 BKWD 

SWAP-FILE  MAP 

PTR 

1 SWAP-FILE 

UAL 

1 

Four 

words  that 

hold  the 

Swap-File 

base  map 

entries . 

The  first  two  words  are  the  first  Swap-File  Map  entry 
and  the  last  two  words  are  the  last  entry.  Entry  format 
is  identical  to  the  general  Swap-File  Map  entry  format. 
The  Swap-File  UAL  is  defined  to  be: 

(Swap-File  LAL)  + (Swap-File  size) 

in  64-word  blocks.  At  assembly  time  .ESMAP  upper  points 
to 

.ESMAP+2,  and  .ESMAP+3  upper  points  to  .ESMAP+1. 

.ESORG  - Master  IC&I  Stack  Origin 

This  symbol  locates  the  beginning  of  the  Master  IC&I 
stack  used  for  transfer  of  control  between  TPOS 
executive  routines.  See  .ESTAK, 
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.ESTAK  - Master  IC&I  Stack 

This  symbol  locates  the  first  word  past  the  Master  IC&I 
stack  used  for  transfer  of  control  between  TPOS 
executive  routines.  The  size  of  this  stack  is 
established  as  the  difference  between  . ESTACK  and 
.ESORG.  This  symbol  is  used  to  locate  the  stack  since 
entries  are  inserted  from  high  to  low  address,  i.e,, 
via  Dl-type  tally  modification. 


.ESTAL  - Stalled  Scheduler  Vector  (CC-Ref) 

0 _ ^ 

|IC  & I WHERE  TRANSACTION  SCHEDULER  STALLED-OUT  or  ZERO! 

The  Transaction  Scheduler  uses  this  cell  as  a flag, 
everytime  it  is  enabled  by  the  Dispatcher  at  the 
main-level,  to  determine  if  it  has  stalled-out  and 
needs  to  be  restarted.  When  the  scheduler  is  stalled, 
.ESTAL  is  treated  as  a vector  that  holds  the  IC  & I 
where  the  Transaction  Scheduler  stalled-out  and  is  to 
be  restarted.  When  this  cell  is  zero,  the  scheduler  is 
enabled  at  the  courtesy-call  level. 


.ESTIM  - Startup  Time 

0 __  35 

1 STARTUP "time  (1/64  MS) ' 1 L 

This  word  holds  the  startup  time  at  the  completion  of 
initialization. 


.ESWPE  - Swap  Eligible  TASK  Count  (CC-Ref) 

g_  35 

I#  OF  SWAP-ELIGIBLE  TASKS  or  KEYWORD  PROCESSORS T 

This  cell  holds  the  count  of  the  number  of  TASKS  whose 
associated  Keyword  Processors  are  eligible  to  be 
swapped  out  of  core.  This  condition  is  indicated  within 
a TASK  when  its  B.TESW  bit  flag  is  on  in  cell  .TFLAG. 
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.ESYMT  - Symbol  Table 


0  17_  18 ^26 ^ 

1 ' i # 'of  table  I ’ " I 

[SYMBOL  TABLE  PTR J ENTRIES  | MBZ [ 

This  word  is  used  to  access  the  symbol  table  if  one  has 
been  built.  If  no  symbol  table  exists,  this  word  is  all 
zeros.  See  symbol  table  description. 


.ETACK  - Dispatcher's  TASK  Alarm  Clock 

0  __35 

ITfME  WHEN  NEAREST  TASK  ALARM  CLOCK  “iS  TO'  RING  (1/64  'rnsR 

1 ALL  ONES  IF  NO  TASK  ALARM  CLOCKS  ARE  SET  I 


This  cell  is  used  as  a wake-up  indicator  for  those 
Keyword  Processors  that  have  issued  a MME  GEWAKE.  The 
alarm  clock  is  set  to  the  nearest  time  when  a TASK 
alarm  clock  is  to  ring  and  its  Keyword  Processor 
awakened.  If  no  TASK  alarm  clocks  are  set,  this  clock 
IS  turned  off  by  setting  it  to  -1  (all  ones).  The 
Dispatcher ' s-Queue  Service  checks  if  the  alarm  is 
ringing. 


.ETASK  - TASK  Space 


0 

17  18 

35 

IPTR  TO  LAST  ASSIGNED 

IPTR  TO  FIRST  FREE 

T 

[TASK  ENTRY  SPACE+l 

[TASK  ENTRY 

1 

UTetksz) 

T' 

T 

[TASK  ENTRY  SIZE 

1 B.TNST 

1 

These  cells  are  used  to  manage  the  unassigned  TASK 
entries  as  an  available  chain.  The  cells  are  defined  by 
the  Generate  TASK  Space  macro  (.TASK.).  .ETASK  upper  is 
assembled  to  point  to  the  first  word  past  the  assigned 
space  and  .ETASK  lower  is  assembled  as  the  location  of 
the  first  assigned  TASK  entry.  .ETKSZ  lower  holds  a bit 
mask  used  to  allow/disallow  need-spawn-TASK  requests 
within  the  Dispatcher ' s- Queu  Service.  To  allow 
requests,  the  mask  is  'ORed'  into  .EDQSM,  while  to 
ignore  requests,  the  I’s  complement  of  the  mask  is 
' ANDed ' with  .EDQSM.  The  mask  bit  position  is  assigned 
in  accordance  with  the  bit  position  of  the  'need  Spawn 
TASK'  (B.TNST)  TASK  Status  Flag. 
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•ETBUF  - Terminal  Buffer  Space  (CC-Ref) 

0 17  18  35 


IPTR  TO  LAST  ASSIGNED 
1 TERMINAL  BUFFER  SPACE  +1 

1 PTR  TO  FIRST  FREE  1 

[TERMINAL  BUFFER  1 

[TERMINAL  BUFFER  SIZE 
1 

[MBZ  [ 

1 1 

These  cells  are  used  to  manage  the  unassigned  terminal 
buffer  space  as  an  available  chain.  The  cells  are 
generated  by  the  .LINE.  macro.  .ETBUF  upper  is 
assembled  to  point  to  the  first  word  past  the  assigned 
terminal  buffer  space  and  .ETBUF  lower  is  assembled  to 
point  to  the  first  word  of  the  assigned  buffer  space. 


.ETCBP  - Terminal  Control  Block  Chain 


0 

17  18 

35 

[FWD  TCB  CHAIN  PTR 
lor  ZERO 

[BKWD  TCB 
[or  ZERO 

CHAIN  PTR  1 

1 

This  cell  holds  the  base  forward  and 
to  the  head  and  tail  of  the  TCB  chain, 
empty,  this  word  is  zero. 

backward  pointers 
If  the  chain  is 

.ETCBT  - Terminal  Control 

Block  Space 

0 

17  18 

35 

[PTR  TO  LAST  ASSIGNED 
[TCB  SPACE  +1 

1 1 
[PTR  TO  FIRST  FREE  TCB  [ 

[TCB  SIZE 
1 

[MBZ 

1 

1 

[ 

These  cells  are  used  to  manage  the  unassigned  Terminal 
Conrrol  Block  (TCB)  space  as  an  available  chain.  Both 
cells  are  defined  at  assembly  time  by  the  .LINE,  macro. 
.ETCBT  upper  is  assembled  to  poinc  to  the  first  word 
past  the  assigned  TCB  space  and  .ETCBT  lower  is 
assembled  to  point  to  the  first  word  of  the  assigned 
TCB  space. 


.ETIME  - System  Time 
0 

TsYSTEM  time  (1/64  ms)' 


35 
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This  cell  holds  the  system  time  when  the  Dispatcher's 
TASK  Alarm  Clock  (.ETACK)  was  last  checked  to  see  if  it 
was  ringing.  The  alarm  clock  is  said  to  be  ringing 
whenever  .ETIME  > .ETACK.  This  cell  is  used  to 
individually  wake-up  the  sleeping  Keyword  Processors. 


.ETIMQ  - Time  Quantum 


0 35 


ILAST  GELRAR  TIME  QUANTUM  (1/64  ms)  I 

This  word  holds  the 

time  quantum  set 

for 

the  last 

Keyword  Processor  GELBAR 

in  1/64  ms.  The  cell 

is  set 

by 

the  Dispatcher  whenever 

it  issues  a GELBAR, 

except  when 

it  reissues  a GELBAR 
interrupt. 

that  was  broken 

by 

an 

I/O 

.ETKSZ  - TASK  Size 

The  upper  half  of  this 

cell  is  set  during 

assembly 

to 

the  TASK  entty  size  by  the  .TASK.  macro. 

1 1 

must 

be 

paired  wirh  cell  .ETASK. 

(See  .ETASK.) 

, ETREG  - TASK  Processor 

Registers 

0 

17  IB 

35 

IPTR  TO  TASK  PROCESSOR 
1 REGISTER  STORAGE  AREA 

INOT  USED 
1 

1 

1 

The  upper  half  of  the  cell  holds  a pointer  to  the 
processor  register  safe-storage  area  of  the  last 
Keyword  Processor  that  was  dispatched  to.  This  area 
starts  at  .KREG  in  the  Keyword  Processor's  Prefix.  The 
value  of  the  pointer  is  relative  to  the  Executive's 
LAL.  This  cell  is  set  by  the  Dispatcher  and  is  used 
during  fault  and  interrupt  processing. 
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Communication  Region  Accumulated  Counts 

Several  counters  are  maintained  by  the  Executive 
for  use  in  evaluating  its  overall  action  and 
efficiency.  The  counters  are  separated  from  the  other 
Communication  Region  cells  since  they  are  not  a 
necessary  part  of  the  Executive's  operating  structure. 

The  general  symbol  for  an  accumulated  count  is 
.ENxxx,  A complete  word  is  dedicated  to  each  counter 
with  the  count  always  r ight-justif ied  in  the  cell.  The 
accumulated  counts  and  their  content  are: 

.ENABT  Total  Abnormal  Keyword  Processor  Terminations 
.ENCRI  Core  Reductions  for  Input  Buffer  Overflow 
.ENCRO  Core  Reductions  for  Output  Buffer  Overflow 
.ENDSP  Total  Dispatches  (GELBARs  Issued) 

.ENGI  Total  GELBARs  Interrupted 

.ENIOC  Input  Buffer  Overflows  Completed 

.ENLRT  Total  Lost  Read  Interrupts 

.ENLWI  Total  Lost  Write  Interrupts 

. ENMLA  Total  Main-Level  Core  Allocations 

.ENMLS  Total  Main-Level  Swap  Allocations 

.ENNML  Total  Normal  Keyword  Processor  Terminations 

. ENOOC  Output  Buffer  Overflows  Completed 

. ENRCV  Total  Transactions  Received 

.ENRLQ  Total  executive  Relinquishes 

.ENRLT  Total  Resource  Lockup  Thresholds 

.ENSAR  Total  Swap  Allocation  Refusals 

.FNSWP  Total  Keyword  Processor  Swap-outs 
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. ENTSS 
. ENIBO 
. ENOBO 


Total  Transaction 
Input  Buffer  Over 
Output  Buffer  Ove 


COMMUNICATION  REGION 

Scheduler  Stall-outs 
flows 
r f lows 
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TRANSACTION  ATTRIBUTES  & STATUS  KERNEL  (TASK) 


A TASK  is  built  and  assigned  to  each  input 
transaction  received  by  the  Executive.  The  TASK  is  used 
to  concentrate  transaction  related  information  in  one 
central  area,  thereby  allowing  easy  access  and  control 
of  the  transaction's  processing  specifics. 


The  TASK  is  linked  to  all  high-usage  internal 
queues  by  assigning  the  queue-entry  within  the  TASK 
itself.  With  this  method,  the  queues  appear  as  threads 
of  forward  and  backward  linked  TASKS.  The  TASK  concept 
aids  queue  processing  by  making  all  transaction 
dependent  control  information  appear  as  if  it  were  in 
each  queue-entry. 


TASK  space  is  generated  within  the  Executive  by 
means  of  the  .TASK.  macro.  This  space  is  assembled 
under  the  ..TASK  location  counter  as  a contiguous  area 
after  the  Keyword  Processor  Profiles.  This  region  is 
managed  by  Communication  Region  cell  .ETASK  with  the 
TASK  size  recorded  in  the  upper  half  of  .ETKSZ. 


TASK  Assignments 


The  TASK  is  defined  symbolically  to  allow  for 
future  modifications  and  additions.  All  TASK  symbols 
are  of  the  form  .Txxxx. 


The  TASK  layout,  with  currently  assigned  offset 
symbols  and  contents,  is  illustrated  on  the  next  page. 
The  layout  is  followed  by  a brief  description  of  each 
TASK  entry. 
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TASK  FORMAT 


Offset 

Notes 


0 

8 9 

17  18 

35 

.TNUMB 

1 

TRANSACTION  NUMBER 

[ 

.TSID 

T 

SOURCE-ID 

Tl (KEYWORD  PROFILE) 

r 

.TIN 

T 

TRANSACTION  INPUT  TIME 

(1/64  ms) 

[ 

•TLAPS 

1 

ELAPSED  PROCESSOR  TIME 

(1/64  ms) 

1 

.TTIMS 

T 

TIME  OF  LAST  SWAP-OUT  or 

1 

ELAPSED  PROCESSOR  TIME 

SINCE  LAST  LOAD  (1/64  ms) 

1 

.TTIMQ 

1 

TIME  REMAINING  FROM  LAST  GELBAR  (1/64  ms) 

1 

.TEAR 

T 

CORE  LAL  ICORE  SIZE 

IL(.KREG)  Executive  LAL 

~f 

1 

IC  Keyword  Processor  LAL 

1 I 

1 

.TPRIO 

E 

1 

1 

FWD  DSP-Q  PTR  or 
BKWD  CORE-Q  PTR 

1 PRIORITY 
1 

1 

1 

.TFLAG 

1 

BKWD  DSP-Q  PTR 

IQ-SCANNED  STATUS  FLAGS 

1 

1 

SERVICE  VECTOR 

[ATTRIBUTE  6.  STATUS  FLAGS 

1 

.TMEM 

T 

FWD  CORE-MAP  PTR  or 

TCORE-HOLE  size  or 

T 

1 

FWD  CORE-Q  PTR 

[CORE  DEMAND  SIZE 

[ 

.TLAL 

1 

1 

BKWD  CORE-MAP  PTR 

[CORE  PARTITION  LAL  or 
[BYPASS  COUNT 

[ 

1 

.TSWAP 

1 

*1  SWAP-FILE  BLOCK  ADDRESS  [KEYWORD  PROCESSOR  SIZE 

[ 

.TMSG 

1 

LOC  OF  INPUT  MESSAGE  Or 

[INPUT  MESSAGE  SIZE  or 

1 

1 

FIRST  OUTPUT  MESSAGE 

[ACCUMULATED  OUTPUT 

[ 

1 

SEGMENT 

[MESSAGE  SIZE 

1 

• TMSG2 

1 

LOC  OF  LAST  OUTPUT 

[ # OF  LINKED  INTERCOM 

[ 

1 

MESSAGE  SEGMENT 

1 Q-ENTRIES 

[ 

.TIDCW 

1 

PSEUDO  INTERCOM  DCW 

[ 

.TERRM 

1 ERROR  CODE 

[NOT  USED 

T 

.TSPWN 

T 

FWD  SPAWN  TASK  PTR 

1 BKWD  SPAWN  TASK  PTR 

T 

.TWAKE 

1 

WAKE-UP  TIME  FOR  GEWAKF 

ALARM  CLOCK  (1/64  ms) 

[ 

. TCCV 

1 

LOC  OF  COURTESY-CALL 

[TSX7  COURTESY-CALL 

[ 

1 

ROUTINE 

[ VECTOR 

[ 

• TPAD 

1 

RESERVED  FOR  CORE  ALLOCATOR 

1 

.TAREG 

8 

1 

EIS  ADDRESS  REGISTERS  SAVED  HERE  (8  WORDS) 

[ 

.TEPL 

8 

T 

EIS  POINTERS  & LENGTHS 

REGISTERS  SAVED  HERE  (8  WORDS) [ 

.TPUSH 

1 

PTR  TO  .TALLY 

[RESERVED  [ DI-MOD 

[ 

.TPOP 

1 

PTR  TO  .TALLY 

[RESERVED  [ ID-MOD 

[ 

.TALLY 

1 

PTR  TO  ( .STAK42+SIZE) 

[-(STACK  SIZE)  [ MBZ 

. TSTAK 

1 

TASL  IC&I  STACK 

[ 

1 

L 

E Even  offset 
8 0 Mod  8 offset 
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•TALLY  - TASK  Stack  Tally  Word 

This  cell  holds  the  tally  word  used  to 
control  the  TASK  stack.  It  is  used  for  entry 
pushdown,  popup  and  stack  reference.  The 
address  portion  of  the  tally  word  is 
initialized  to  point  to  the  last  word  in  the 
stack  plus  one,  since  entries  are  inserted 
from  high  to  low  address.  The  tally  count  is 
initialized  to  minus  the  stack  size.  This 
cell  always  points  to  the  current  stack 
entry,  provided  the  stack  isn't  empty,  so 
that  it  can  be  used  as  an  indirect  to 
reference  the  stack. 

.TAREG  - EIS  Address  Registers 

This  is  an  eight  word  area  used  to  hold  the 
eight  EIS  address  registers  if  configured. 
This  area  must  have  a 0 mod  8 offset.  The 
format  for  word  n of  this  area  is  as 
follows : 

BITS  0-23  = c(ARn) 

Bits  24-35  = 0 

.TEFL  - EIS  Pointers  & Lengths  Registers 

This  is  an  eight  word  area  used  to  hold  the 
eight  EIS  pointers  and  length  registers. 
This  area  must  have  a 0 mod  8 offset. 

.TNUMB  - Transaction  number 

Binary  transaction  number  assigned  to  the 
transaction  described  by  the  TASK. 

.TPOP  - Popup  for  TASK  IC&I  Stack 

This  cell  is  an  indirect  word  that  points  to 
the  TASK  IC&I  stack  tally  word  at  .TALLY 
with  ID-type  tally  modification.  The  cell  is 
used  for  removing  an  entry  from  the  TASK 
ICM  stack.  The  pointer  to  .TALLY  is  an 
absolute  address  relative  to  TPOS's  I,AI.. 
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.TPUSH 


.TSID 


, TSTAK 


• TIN 


.TLAPS 


•TTIMS 


- Pushdown  for  TASK  IC&I  Stack 

This  cell  is  an  indirect  word  that  points  to 
the  TASK  IC&I  stack  tally  word  at  .TALLY 
with  Dl-type  tally  modification.  The  cell  is 
used  for  making  an  entry  into  the  TASK  IC&I 
stack.  The  pointer  to  .TALLY  is  an  absolute 
address  relative  to  TPOS ' s LAL. 

- Source-ID 

Bits  0-19  contain  the  Source-ID  specified  in 
the  transaction  header. 

Bits  18-35  contain  a pointer  to  the  first 
word  of  the  Keyword  Processor  Profile 
associated  with  the  transaction  designated 
keyword . 

- TASK  IC&I  Stack 

This  symbol  locates  the  TASK  IC&I  stack, 
which  must  be  the  last  entry  in  a TASK  due 
to  the  manner  in  which  the  stack  size  is 
established.  The  size  of  the  stack  is  set  by 
the  .TASK,  macro.  The  stack  is  used  by  the 
transfer  of  control  macros. 

- Time-In 

Transaction  input  time  (in  l/64th 
millisecond  pulses)  when  received  by  TPE. 
Time  is  obtained  from  the  transaction 
header . 

- Elapsed  Processor  time 

Total  processor  time  used  by  the  associated 
key  processor  in  1/64  millisecond  pulses. 

- Swap  Timer 

Elapsed  processor  time  since  last  load  or 
swap-in  if  Keyword  Processor  is  in-core, 
otherwise  time  of  day  of  last  swap-out.  All 
times  in  1/64  millisecond  pulses. 
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•TTIMQ  - GELBAR  Time  Quantum 

GELBAR  Time  remaining  from  last  dispatch,  in 
l/64th  millisecond  pulses.  Zero  if  a 
timer-runout  occurred  since  last  dispatch. 

.TBAR  - Keyword  Processor  Base  Address 

Bits  0-8  contain  the  Keyword  Processor's 
base  address  (in  even  multiples  of  512 
words)  relative  to  the  Executive. 

Bits  9-17  contain  the  size  (in  even 
multiples  of  512  word)  of  the  core  partition 
assigned  to  the  Keyword  Processor. 

Bits  18-35  contain  the  pointer  to  the 
Keyword  Processor's  register  safe-store  area 
relative  to  the  Executive. 

.Tier  - Return  IC  & I 

Bits  0-19  contain  the  instruction  counter 
relative  to  the  Keyword  Processor  where 
control  is  to  be  returned  when  its  next 
GELBAR  dispatch  is  paid. 

Bits  18-35  contain  the  Keyword  Processor's 
Indicator  Register. 

.TPRIO  - Priority 

Bits  0-19  can  contain  a backward  Core-Queue 
pointer  or  a forward  Dispatcher ' s-Queue 
pointer . 

Bits  18-35  contain  the  transaction's 
priority.  The  offset  assignment  for  this 
cell  must  always  be  even. 

.TFLAG  - Bit  Flags 

Bits  0-19  contain  a backward 
Dispatcher ' s-Queue  pointer. 

Bits  18-35  contain  TASK  and  Keyword 
Processor  Status  bit  flags.  Bit  definitions 
are  described  later. 
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•TFLAG+1  - Bit  Flag  Continuation 

Bits  0-19  contain  a service  vector  which 
holds  the  IC  of  a system  service  or 

functions. 

Bits  18-35  contain  Status  and  Attribute  bit 
flags. 

Bit  definitions  are  described  later. 

.TMEM  - Memory 

If  linked  to  the  Core-Queue: 

Bits  0-17  contain  a forward  Core-Queue 
pointer , 

Bits  18-35  contain  the  core  demand  size  in 
1024-word  multiples. 

If  linked  to  the  Core-Map: 

Bits  0-17  contain  a forward  Core-Map 
pointer , 

Bits  18-35  contain  the  size  of  the  free 
hold  following  the  core  partition  defined 
by  this  map  entry  in  1024-word  multiples. 

.TLAL  - Lower  Address  Limit 

If  linked  to  the  Core-Queue: 

Bits  0-17  are  not  used, 

Bits  18-35  contain  the  current  bypass 
count  of  this  demand. 

If  linked  to  the  Core-Map: 

Bits  0-17  contain  a backward  Core-Map 
pointer , 

Bits  18-35  contain  the  LAL  of  the  core 
partition  defined  by  this  map  entry. 
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TSWAP 


TMSG 


TMSG2 


TIDCW 


- Swap-File  Information 

Bit  0 holds  a flag  to  identify  on  which  file 
the  Keyword  Processor  is  saved.  The  $L 
load-file  is  flagged  by  a zero  and  the  $S 
Swap-file  is  flagged  by  a one. 

Bits  1-17  contain  the  starting  Load/Swap 
file  block  address,  in  64-word  blocks. 


Bits  18-35  contain  the  number  of  blocks 
needed  to  hold  the  Keyword  Processor  on  the 
$L  Load-File. 

- Input/Out  Message  Control 


For  an  input  message: 


Bits  0- 

17  - 

contain  a po 

inter 

to 

the 

input 

message 

w 

ithin  the 

first 

wor 

d aft 

er  the 

appl ica 

ble 

buffer  map 

entry 

• 

Bits  18 

-35 

contain  the 

size 

of 

the 

input 

message 

in 

v'or  ds . 

ir  an  ou 

tpu 

t message: 

Bits  0 

-17 

contain  a 

poi  nti 

er  t 

o the 

first 

output 

mes 

sage  segment 

with 

in 

the 

Output 

Intercom  Buffer.  This  points  to  the  first 
message  word,  not  the  buffer  map  entry. 

Bits  18-35  contain  the  accumulated  output 
message  size  of  all  message  segments 
serially  linked  to  the  first  segment.  This 
size  includes  each  segment's  header. 

- Output  Message  control 


Bits  0-17  contain  a pointer 
linked  output  message  segment. 


to  the  last 


Bits  18-35  contain  a count  of  the  number  of 


Output  Intercom-Queue 
this  TASK. 


entries  assigned  to 


- Pseudo  Intercom  DCW 

This  word  holds  the  Keyword  Processor's 


TASK 


.TERRM 


•TSPWN 


.TWAKE 


.TCCV 


.TRAD 


Intercom  DCW 

when 

input 

IS  requested. 

The 

DCW' s 

relative  to  the  Executive 

Error  Message 

Code 

Bits  0-17  contain 

the 

message  code 

if 

the 

Processor  is  abnormally  te 


or  output  Intercom 
data  address  is 
LAL. 


Executive  error 
TASK  or  Keyword 
rminated. 


Bits 
- TASK 


18-35  are  reserved. 
Spawn  Chain 


If  zero  the  TASK  does 
Chain,  otherwise: 

not  belong 

to  a 

Spawn 

Bits  0-17 
pointer . 

contain  a 

forward 

Spawn 

TASK 

Bits  18-35 
pointer . 

contain  a 

backward 

Spawn 

TASK 

- Wake-up  Time 

Bits  0-35  contain  the  time  this  TASK'S 
Keyword  Processor  is  to  be  awakened.  This 
cell  is  set  by  a GEWAKE. 


- Courtesy-Call  Vector 

Bits  0-17  contain  the  location  of  the 
courtesy-call  routine. 


Bits  18 
transfer 
routine 
with  the 


35  contain  a TSX7  instruction  to 
control  to  the  courtesy-call 
and  to  identify  the  TASK  associated 
completed  I/O. 


- Scratchpad 

This  symbol  is  associated  with  one  or  more 
cells  that  the  end  of  the  TASK,  dependinq  on 
the  assembled  TASK  size.  The  first  cell, 
that  is  the  cell  addressed  as  .TPAD,  is 
reserved  for  the  Core  Allocator. 


If  the  TASK 


is  linked 


to  the  Core-Queue: 
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Bits  0-17  contain  a pointer  to  the  next 
lower  priority  no-pass,  or  zero  if  this 
TASK  is  the  lowest  priority  no-pass. 

Bits  18-35  contain  a pointer  to  the  next 
higher  priority  no-pass  or  zero  if  this 
TASK  is  the  highest  priority  no-pass. 

If  the  task's  Keyword  Processor  is  being 
swapped-in : 

Bits  0-17  are  not  used. 

Bits  18-35  contain  the  Keyword  Processor's 
required  core  size. 

If  the  task's  Keyword  Processor  is  being 
swapped-out : 

Bits  0-17  contain  a pointer  to  the 

replacement  TASK  (the  TASK  to  be 

swapped-in) . 

Bits  18-35  contain  the  Keyword  Processor's 
LAL. 


TASK  STATUS  AND  ATTRIBUTE  FLAGS 


TASK  Status  and  Attribute  Flags  are  bit  flags.  The 
bit  position  assignment  of  the  flags  is  defined 
symbolically  with  general  symbol  formations  of  B.Txxx 
for  TASK  Status  Flags  and  B.Axxx  for  Attribute  Flags. 


Only 

TASK  Status 

Flags  are 

allowed  i 

n .TFLAG 

lower.  Flags  present  in 

.TFLAG+1  are 

both  Sta 

tus  and 

Attribute 

Flags . 

Care 

should  be 

exercised  when  examini 

ng  a bit 

tlag(s)  to 

ensure  that 

the  proper 

TASK  cell 

r i . e . , 

.TFLAG+1 , 

is  being  used 
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TASK  Status  Bit  Flags 


TASK  Status  Bit  Flags  are 
indicate  the  current  state  of 
associated  Keyword  Processor.  By 
is  meant  which  queues  the  TASK  is 


dynamic  flags  used  to 
the  TASK  and  its 
the  state  of  the  TASK 
linked  to. 


m 


TASK  Status  Flags  in  .TFLAG  are  called  'Q-scanned'  « 
flags.  Their  usage  is  somewhat  specialized  as  explained  m 
in  the  Dispatcher ' s-Queue  and  Dispatcher ' s-Queue  9 
Service  discussions  later.  9 


TASK  Status  Flags  in  . TFLAG 


B.TABT  - In  Abort 

This  flag  indicates  that  the  TASK  and  its 
associated  Keyword  Processor  (if  one  exists) 
are  being  abnormally  terminated  by  the  TASK 
Terminator . 


B.TABW  - In  Abort  Wrap-up 

This  flag  has  been  defined,  but  currently  is 
not  implemented. 

B.TDIO  - Device  I/O  Initiated 

This  flag  is  set  on  when  device  I/O  is 
requested  and  subsequently  initiated  by  the 
Executive.  The  flag  is  used  in  determining 
Dispatch  Select  and  Swap-out  eligibility  and, 
during  abort  or  termination  processing,  to 
ensure  that  all  device  I/O  is  completed  before 
core  assigned  to  the  Keyword  Processor  is 
released. 

' - Eligible  for  Swap 

: : s flag  indicates  that  an  in-core  Keyword 
: r r.ior  is  eligible  to  be  swapped-out.  The 
• ii  1 r;  reuuired  since  swapping  is  not 
' irily  initiated  when  the  eligibility 
• • ■.".)*  i ''n  is  made.  Consequently,  the  flag 

• * *‘)»^n  searching  for  an  in-core  Keyword 


M . 1 0 


TASK 


B.TNBS 


B.TNQE 


B .TNST 


Processor  that  can  be  swapped-out  and 
replaced . 


Need  Abort 

This  flag  indicates  that  the  associated 
Keyword  Processor  is  awaiting  abnormal 
termination  processing. 


Need  Output  Buffer  Space 

This  flag  indicates  that  the  associated 
Keyword  Processor  is  unable  to  get  its 
requested  amount  of  Output  Intercom  Buffer 
space.  This  condition  suspends  the  requesting 
Keyword  Processor  from  further  execution  until 
sufficient  space  can  be  assigned.  The 
Dispatcher  will  attempt  to  restart  the  service 
for  this  TASK  during  its  queue  service. 


Need  Output  Intercom-Queue  Entry 

This  flag  is  set  on  when  the  Output 
Intercom-Queue  is  full  so  that  there  are  no 
available  Output  Intercom-Queue  entries  to  be 
assigned  to  the  associated  Keyword  Processor. 
This  condition  suspends  the  requesting  Keyword 
Processor  from  further  execution.  The 
Dispatcher  will  attempt  to  restart  the  service 
for  this  TASK  during  its  queue  service. 


- Need  Spawn  TASK 


This  flag  indicates  that  the  associated 
Keyword  Processor  is  awaiting  a skeleton  TASK 
in  order  to  initiate  Keyword 
Pr ocessor -to-Keywor d Processor  Intercom 
communication.  This  condition  suspends  the 
requesting  Keyword  Processor  from  further 
execution.  The  Dispatcher  will  attempt  to 
restart  the  service  for  the  TASK  during  its 
queue  service. 


1 
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B.TSWO  - Swap-Out  in  Progress 

This  flag  is  set  on  when  swap-out  of  the 
associated  Keyword  Processor  has  been 
initiated  and  turned  off  when  the  swap-out  has 
been  completed.  The  Keyword  Processor  cannot 
be  dispatched  to  when  this  flag  is  on,  even 
though  the  TASK  remains  linked  to  the 
Dispatcher 's-Queue. 


B.TTRM  - In  Termination 

This  flag  indicates  that  the  TASK  and  its 
associated  Keyword  Processor  are  being 
terminated  by  the  TASK  Terminator. 


B.TWAK  - Need  Wake-up 

This  flag  is  set  on  when  the  associated 
Keyword  Processor  issues  a MME  GEWAKE.  The 
wake-up  time  is  kept  in  TASK  cell  .TWAKE.  The 
flag  is  used  by  the  Dispatcher ' s-Queue  Service 
to  awaken  the  Keyword  Processor  when  its  alarm 
clock  rings. 


TASK  Status  Flags  in  . TFLAG+l 

B.TBIO  - Building  Intercom  Output 

This  flag  signals  that  the  Executive  has 
leceived  an  output  Intercom  I/O  request  from 
the  associated  Keyword  Processor  and  that  the 
TASK  message  pointer  word  .TMSG  describes  an 
output  message.  The  flag  is  used  to  help 
determine  whether  an  output  message  segment  is 
the  first  segment  received  or  a subsequent 
segment  which  must  be  linked  to  a message 
chain. 


B.TFLT  - ZOP,  CMD,  MEM,  TAG  Fault 

This  flag  is  set  on  whenever  a Keyword 
Processor  ZOP,  CMD,  MEM,  or  TAG  fault  occurs. 
The  flag  is  used  in  subsequent  fault 
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processing  to  determine  whether  control  should 
be  returned  to  the  Keyword  Processor. 

B.TINC  - In-Core 

This  flag  indicates  that  the  TASK  is  linked  to 
the  Core-Map  and  its  Keyword  Processor  is  in 
core.  As  such,  TASK  cells  .TMEM  and  .TLAL  are 
a Core-Map  entry  with  the  upper  halves  of  the 
cells  holding  map  link  pointe»s. 


B.TITY  - Input  Message  Type 

This  flag  indicates  that  the  input  message  was 
created  as  output  from  another  Keyword 
Processor  and  not  directly  by  the  user.  The 
TASK  message  pointer  in  .TMSG  no  longer  points 
to  the  Input  Buffer  but  to  the  (linked)  output 
segments  in  the  Output  Buffer.  The  flag  is  set 
on  by  the  Output  Intercom  I/O  routine  after  a 
TASK  has  been  built  for  an  output  message 
specifying  Keyword  Processor-to-Keywor d 
Processor  Intercom  communication. 


B.TLCQ  - Linked  to  Core-Queue 

When  this  flag  is  on,  the  TASK  is  linked  to 
the  Core-Queue.  As  such,  TASK  cells  .TPRIO, 
.TMEM  and  .TLAL  represent  a Core-Queue  entry 
with  the  upper  halves  of  the  first  two  cells 
holding  queue  link  pointers. 


B.TLDQ  - Linked  to  D ispatcher ' s-Queue 

This  flag  is  set  on  when  the  TASK  is  linketJ  to 
the  Dispatcher ' s-Queue.  As  such,  TASK  cells 
.TPRIO  and  .TFLAG  represent  a queue  entry  with 
the  upper  halves  of  these  cells  holding  queue 
link  pointers. 


B.TNUT  - New  TASK 

This  flag  is  set  on  when  a skeleton  TASK  is 
built  and  assigned  to  an  input  message.  The 


8.13 


TASK 


flag  is  used  by  the  set-up  swap  I/O  routine  to 
determine  whether  a DOW  for  the  Keyword  Prefix 
Area  (KPA)  is  to  be  built  and  by  the  swap-in 
courtesy-call  to  determine  if  KPA 
initialization  is  necessary.  The  flag  is  set 
off  by  the  swap-in  courtesy-call.  The  flag  is 
also  used  during  termination  processing  when 
the  Core-Queue  is  searched  for  a new  TASK  that 
can  be  assigned  to  a transaction  reentrant 
Keyword  Processor. 


B.TOTY  - Output  Message  Type 

This  flag  is  set  on  when  the  first  Intercom 
output  segment  of  a message  has  a single 
destination  of  ***.  This  destination  indicates 
Keyword  Processor  Intercom  communication; 
therefore,  this  output  is  designated  as  input 
to  another  Keyword  processor. 


B.TOUC  - Output  Complete 

This  flag  is  set  on  by  the  Output  Intercom  I/O 
routine  when  an  EOT  (End-of-Transact ion) 
status  is  detected  in  an  output  message 
segment.  The  flag  is  used  by  the  Intercom  I/O 
Handler  to  determine  if  a Keyword  Piocessor 
has  finished  processing. 

B.TRLQ  - Relinquish/Roadblock  Requested 

This  flag  is  set  on  when  a Keyword  Processot 
, issues  a MME  GERELC  ot  GEROAD  and  turned  off 
’ whenever  I/O  (device  or  Intercom)  is 

requested.  The  flag  is  used  to  prevent  the 
Keyword  Processor  from  issuing  two  consecutive 
GEREbC/GEROADs  without  an  intervening  I/O. 


B.TWSI  - Swap-In  in  Progress 

This  flag  indicates  that  the  associated 
Keyword  Processor  is  being  loaded  or 
swapped-in.  The  flag  is  used  during  abnormal 
termination  to  ensure  that  all  I/O  is  complete 
befo'"e  assigned  core  is  released. 
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This  flag  is  set  on  when  the  associated 
Keyword  Processor  has  been  swapped-out  and 
thus  resides  on  the  $S  Swap-File.  When  the 
flag  is  on  a Swap-Map  entry  has  been  assigned 
to  this  TASK  and  TASK  cell  .TSWAP  upper  holds 
the  starting  block  number  of  the  assigned 
Swap-File  space. 
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Attribute  Bit  Flags 


Attribute  Flags  are  set 
by  the  parameters  suppl 
Profile  macro  .PRFL. 
profile  are  static  duri 


during  the  Executive's  a 
ied  to  the  Keyword  Pr 
The  flag  settings  with 
ng  execution. 


ssembly 
ocessor 
in  each 


Every  time  a transaction  is  received,  all  Attribute 
Flags  accessible. 


Attribute  Flags  in  .TFLAG+1  and  Keyword  Profile 
B.ADNS  - Do  Not  Swap 

This  flag  indicates  that  the  associated 
Keyword  Processor  is  not  to  be  swapped,  but 
should  remain  in  core  until  it  has  completed 
processing  each  transaction. 

B.ARUS  - Reusable 

This  flag  specifies  that  the  Keyword  Processor 
is  not  disposable,  that  is,  after  processing  a 
transaction  with  normal  termination,  a new 
transaction  can  be  passed  directly  to  the 
Keyword  Processor  with  no  external  setup  or 
initialization  required. 


B.ASEM  - Suppress  Error  Messages 

This  flag  causes  the  transmission  of  all 
Executive  full  text  error  messages  to  the  user 
to  be  eliminated.  In  their  place  the  Executive 
issues  a caveat  to  inform  the  user  that  the 
designated  transaction's  processing  has  been 
aborted.  This  warning  also  specifies  the  error 
code  or  message  number. 


B.AOVL  - Overlays  are  part  of  this  Keyword  Processor 

This  flag  causes  the  Executive  to  search  for 
overlays  when  a MME  GER^^TR  is  executed.  During 
initialization,  the  Keyword  Processor  Profile 
is  built  via  a macro,  if  overlays  are  used  in 


J 
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a Keyword  Processor 
Profile  is  expanded 
necessary  overlay  i 
Flag  is  set. 


, the  Keyword  Processor 
to  accommodate  the 
nformation  and  the  B.AOVL 
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Teiminal  Control  Block 


A Terminal  Control  Block  (TCB)  is  allocated  and 
assigned  to  each  terminal  that  connects  to  TPOS.  All 
identification,  control  and  status  information  required 
to  process  breaks,  I/O  and  disconnects  is  grouped  into 
the  TCB.  In  addition,  other  information  necessary  to 
link  the  TCB  with  a TASK  and  provide  convenient 
terminal  handling  functions  is  contained  in  the  TCB. 


All  TCBs  are  linked  together  via  forward  pointers 
in  .TCTID  of  each  TCB  and  backward  pointers  in  .TCGSS. 
The  forward  pointers  form  a true  linked  chain,  while 
the  backward  pointers  simply  locate  the  previous  TCB  to 
allow  linking/unlinking. 


TCB  space  is  generated  by  the  .LINE,  macro.  This 
space  is  assembled  under  the  ..LINE  location  counter 
together  with  the  terminal  buffer  space.  The  TCB  space 
is  managed  by  Communication  Region  cell  .ETCBT.  The 
.LINE,  macro  is  used  as  follows: 

1 ^ ^6 

.LINE.  NUMBER-OF-TERMINAL-LINES, 

ETC  WAIT-FOR-TERMINAL-RECONNECT-TIME 


where  the  reconnect  time  is  specified  in  seconds. 


TCB  Assignment 


The  TCB  is  symbolically  defined  to  allow  for 
future  modifications  and  additions.  All  TCB  references 
must  be  symbolic.  TCB  symbols  have  been  assigned  the 
general  form  of  .TCXXX. 


The  TCB  layout,  with  currently  assigned  offset 
symbols  and  contents,  is  illustrated  on  the  following 
page.  The  Layout  is  followed  by  a brief  description  of 
each  TCB  entry. 
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TCB  FORMAT 


0 17 

18  23  24  29  30 

35 

.TCTID 

1 FWD  TCB  PTR 
1 

[TERMINAL[TERMINAL  ID 
1 TYPE  [ 

[ 

1 

.TCGSS 

1 BKWD  TCB  PTR 
1 

[GEROUT  SOFTWARE 
[STATUS  BIT  FLAGS 

1 

[ 

.TCCCV 

IRIO  CC  ROUTINE  PTR 
1 

[TSX6  INSTRUCTION- 

INO  ADDRESS  MODIFICATION 

1 

.TCSLP 

lEXT  CC  ROUTINE  PTR 
1 

[TASK  PTR 
1 

[ 

[ 

. TCSTA 

1 

IGEROUT  STATUS  WORD 
1 

[ 

1 

i .TCDAT 

1 CONNECT  DATE  (MMDDYY) 
1 

~J 

[ 

: .TCTIM 

' 

[CONNECT  TIME  (1/64  ms) 
1 

1 

1 

•TCBUF 

[BUFFER  PTR 
[ 

[TALLY  [MBZ 

[ 1 

[ 

[ 

.TCBCW 

[BUFFER  CONTROL  TALLYB  WORD 
[ 

T 

I 

•TCWHO 

1 USER 
1 

1 

1 

1 

Tidentification 

[ 

1 

[ 

1 

BKWD 

- Backwards 

CC 

- Courtesy-Call 

EXT 

- External 

FWD 

- Forward 

ID 

- Identification 

LOC 

- Location 

PTR 

- Pointer 
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Descript 
.TCTID  - 


.TCGSS  - 
.TCCCV  - 


• TCSLP  - 


ion  of  TCB  Entries 


Terminal  Identification 


Bits  0-17  hold  a forward  pointer  to  .TCTID  of 
the  next  TCB,  or  zero  if  this  TCB  is  the  only 
or  last  TCB. 


Bits  18-23  contain  the  Terminal  Type. 


Bits  24-35  contain  the  Terminal 

Identification. 


GEROUT  Software  Status 

Bits  0-17  hold  a backward  pointer  to  .TCTID  of 
the  previous  TCB,  or  zero  if  this  is  the  first 
TCB. 

Bits  18-35  contain  status  and  control  bit 
flags  which  are  described  later. 


Courtesy-Call  Vector 

Bits  0-17  contain  the  location  of  the  GEROUT 
courtesy-call  routine. 


Bits  18-35  contain  a TSX6  with  no  address 
modification.  This  instruction  is  used  to 
identify  the  applicable  TCB  when  a 
courtesy-call  is  paid  and  to  transfer  control 
to  the  appropriate  courtesy-call  routine. 


Procedure/Structure  Pointers 

Bits  0-17  hold  a pointer  to  an  external 
courtesy-call  routine  which  is  to  be  invoked 
when  RIO  receives  the  next  courtesy-call  for 
this  TCB.  If  zero,  no  external  courtesy-call 
is  to  be  paid. 

Bits  18-35  hold  a TASK  pointer  to  the  TASK 
associated  with  this  TCB,  if  any. 
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.TCSTA 


.TCDAT 


.TCTIM 


• TCBUF 


.TCBCW 


I 

! .TCWHO 


li 


GEROUT  Status 

This  word  is  used  to  receive  all  GEROUT  I/O 
status  words. 

Connect  Date  j 

This  word  holds  the  BCD  date,  in  MMDDYY  form, 
when  the  terminal  signed  on  to  TPOS. 


Connect  Time 

This  word  holds  the  time,  in  1/64  ms  pulses, 
when  the  terminal  signed  on  to  TPOS. 


Buffer  Control  Word  Refresher 

Bits  0-17  point  to  the  64-word  buffer  assigned 
to  this  TCB. 

Bits  18-29  hold  a byte  tally  used  to  refresh 
.TCBCW.  The  tally  count  is  set  to  4*64. 

Bits  30-35  are  zero. 


Buffer  Control  Word 

This  word  holds  a byte  tally  word  used  to 
control  data  moved  to  the  buffer  assigned  to 
this  TCB. 


User  Identification 

i 

Two  words  reserved  for  future  use  to  hold  the 
teiminal  user's  Identification. 


i 
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TCB  Status  & Control  Flags  in  .TCGSS 


•STACK  - Acknowledging  GEROUT  45  Status 

This  flag  is  reserved  for  future  use  when 
acknowledging  a status  previously  returned  by 
the  GEROUT  generalized  remote  status  inquiry 
function  (operation  code  45)  . 


•BTBRK  - Outstanding  GEROUT  Break  Status 

This  flag  is  used  to  record  a break  status  on 
the  applicable  line.  The  flag  is  set  in 
response  to  a break  status  returned  by  the 
GEROUT  generalized  remote  status  inquiry 
function  when  there  is  no  outstanding  I/O  to 
the  terminal.  The  flag  is  reset  when  I/O  to 
the  terminal  is  requested,  at  which  time  the 
break  status  is  returned  to  the  caller  without 
actually  attempting  any  I/O. 


.BTCBR  - I/O  Retry  Due  to  Busy  Terminal 


This  flag  is  used  by  RIO  routines  to  allow  one 
retry  of  terminal  I/O  that  results  in  a 
terminal  busy  status.  The  flag  is  set  on  when 
retry  is  in  effect,  after  which  it  is  turned 
off. 


. BTCDW  - Waiting  for  Final  Disconnect 

This  flag  is  set  on  when  a terminal  is 
disconnected  and  has  passed  logon.  The  flag  is 
used  to  reserve  the  TCB  until  a specified  time 
interval  has  passed.  This  implementation 
anticipates  a reconnect  function.  The  flag  is 
examined  by  Line  Service,  which  initiates  the 
final  disconnect  and  release  of  a TCB. 


.BTCIO  - Terminal  I/O  in  progress 

This  flag  is  set  on  whenever  terminal  I/O  is 
initiated.  The  flaa  is  set  off  within  the 
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applicable  courtesy-call  routine  when  paid. 


BTCLO  - Logon  in  Progress 

This  flag  is  turned  on  when  a terminal 
connects  to  TPOS  and  a TCB  is  assigned.  The 
flag  is  set  off  once  the  program  name  question 
has  been  successfully  written  to  the  terminal. 
This  flag  is  used  in  conjunction  with 
disconnect  processing.  if  the  flag  is  on  and 
the  terminal  is  disconnected,  the  TCB  is 
immediately  released.  If  the  flag  is  off,  the 
TCB  is  placed  in  Limbo  for  the  preset  time 
interval  tro  a I i aw  the  user  to  reconnect.  The 
reconnect  feature  is  not  ii  • ’.emented  in  the 
current  version. 


BTDIS  - Outstanding  GEROUT  Disconnect  Status 

This  flag  is  used  to  record  a disconnect 
status  on  the  applicable  line.  The  flag  is  set 
in  response  to  the  receipt  of  a disconnect 
status  from  the  GEROUT  generalized  remote 
status  inquiry  function.  Disconnect  processing 
is  immediately  initiated  for  this  TCB.  The 
flag  is  used  in  the  event  that  any  I/O  is 
requested  for  the  terminal  while  the  TCB  is 
held  in  limbo  awaiting  a possible  reconnect. 
The  flag  is  not  reset. 


BTLSW  - Line  Switch  in  Progress 

This  flag  is  set  when  a line  switch  request  is 
made  via  the  program  name  LSWIT.  The  flag  is 
used  by  Line  Service  to  enable  the  line  switch 
function  for  status  checking  purposes.  When  a 
status  is  returned,  regardless  of  the  line 
switch  outcome,  the  flag  is  reset. 


BTWAI  - Terminal  in  Wait  Status 

This  flag  IS  set  on  when  a wait  request  is 
made  via  the  program  name  WAIT.  The  flag  is 
tested  by  Line  Service  to  enable  the  wait 
function,  since  it  pet  loii  tea  1 ly  'rattles'  the 
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sleeping  terminal  to  reassure  the  user  that 
his  line  is  still  connected.  The  flag  is 
turned  off  when  a break  or  disconnect  is 
received  on  the  line. 
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KEYWORD  PROCESSOR  PR^ILE 
Profile  Function 


Each  Keyword  Processof  Profile  contains  the 
necessary  information,  both  user  supplied  and 

internally  generated,  to  uniquely  identify  the  Keyword 
Processor,  to  locate  the  program  elements  on  the  $L 
Load-File,  to  specify  the  attributes  of  the  Keyword 
Processor  and  to  declare  the  keywords  that  are  to  be 
associated  with  the  Keyword  Processor.  A profile  must 
be  defined  for  each  Keyword  Processor  that  is  to  be 
installed  or  attached  to  the  Executive. 


Profile  Generation 


The  .PRFL.  macro  is  used  to  generate  the  profiles 
into  one  contiguous  area  of  the  Executive  under  the 
..PRFL  location  counter  and  to  generate  the  Keywords 
list  into  another  contiguous  area  under  the  ..KEYL 
location  counter.  A .PRFL.  macro  statement  must  be 
supplied  for  each  Keyword  Processor  that  is  to  be  known 
to  the  Executive. 


Each  profile  is  defined  as  follows: 


8_  16  

.PRFL.  Keyword-Processor-ID, 

ETC  Max  iinum-Output-Message-Size, 

ETC  Max imum-I npu t-Message-S ize , 

ETC  Default-Priority, 

ETC  (Keywor  d-1 (Pr ior  ity (Bypass-Count) ) , 

ETC  Octal-Atr r ibute-Flags , 

ETC  ( Keywor  d-Processor-Attr ibute-1. 
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ETC  Keyword-Processor  Attribute-J) , 

ETC  (Keyword-n (Prior ity (Bypass-Count) ) ) , 

ETC  (Over lay-Name-1 , . . . ,Over lay-Name-M) 

where  the  profile  parameters  are  further  explained 
below . 


The  Keyword-Processor -ID  is  a three  character  BCI 
identification,  which  is  unique  among  all  Keyword 
Processors  assigned  to  the  Executive. 


The  maximum  input  and  output  message  sizes  include 
all  headers  that  prefix  the  segments  making  up  the 
messages.  The  message  sizes  are  given  in  words. 


The  default  priority  is  inserted  into  an  18-bit 
field.  This  value  should  be  assigned  in  consonance  with 
the  default  priorities  assigned  to  the  other  profiles. 


The  Keyword  Processor  attributes  are  designed  to 
describe  the  type  and  characteristics  of  the  Keyword 
Processor  and  to  specify  which  TPOS  options  are  to  be 
applied  to  the  Keyword  Processor.  The  attributes  are 
specified  in  the  macro  call  by  attribute  names,  which 
are ; 


' Reusable ' 

' Do-Not-Swap ' 

' Suppr  ess-Msg ' 


Reusable  Keyword  Processor 
Do  Not  Swap  Keyword  Processor 
Suppress  Error  Messages 


Each  attribute  name  has  a corresponding  B.AXXX 
attribute  bit  flag  assigned  to  it.  The  attribute  bit 
flag  values  are  summed  together  and  this  value  is 
inserted  into  the  profile.  There  is  room  for  nine 
attributes  in  the  profile,  four  of  which  are  currently 
used.  Three  are  explicitly  named  in  the  macro  call, 
while  the  fourth  (B.AOVL)  is  implicitly  inserted 
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whenever  overlay  names  are  specified.  See  the  TASK 
description  for  flag  explanations. 


Each  keyword  is  supplied  with  an  associated 
priority  and  bypass  count.  If  the  keyword  priority  is 
nulled,  the  default  priority  assigned  to  the  profile  is 
used . 


The  bypass  count  must  be  a positive  integer  or 
zero.  This  count  has  a gross  effect  on  the  Core 
Allocator's  handling  of  all  Keyword  Processors  awaiting 
core  assignment;  consequently,  the  count  should  be  set 
to  zero  for  only  the  most  urgent  keywords.  See  the  Core 
Allocator  discussion. 


The  Keyword  Processor  Profile  macros  must  be 
inserted  as  a group  into  the  Executive  prior  to 
assembly . 


Profile  Usage 


The  appropriate  profile  must  be  referenced  for 
every  legal  transaction  received  by  the  Executive.  At 
this  time  some  of  the  profile  information  is  copied  to 
the  TASK  assigned  to  the  transaction. 


The  Keyword  Processor  Profiles  are  located  via 
Communication  Region  cell  .EPRFL.  This  cell  also 
contains  a count  of  the  number  of  profiles.  Similarly, 
the  Keywords  List  is  located  via  cell  .EKEYL,  which 
also  contains  the  total  number  of  keywords  for  all 
prof iles. 


Keyword  Processor  Profile  as  Assembled 

Keyword  Processor  Profiles  are  assembled  into  a 
contiguous  block  using  the  dedicated  location  counter 
..PRFL  with  entry  definitions  formatted  via  the  .PRFL. 
macro  as  follows: 
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0  17  18_  _ 2^27  ^5 

1 PTR  TO  NEXT  PROFILE  " " I KEYWORD-p'rOCESS^OR-ID’  \ 

]m‘aximum_input  message  size  Fmaximum  output  menage  size~T 

_ __  _ I PTR  TO  FIRST  KEYWORD  \_ 

IDEFAULT  PRIO'RITY  ~ ' I FLAGS*  ’ I MBZ  _ ' _|_ 


* Keyword  Processor  Piofile  Attribute  Flags.  See  the 
TASK  discussion  for  an  explanation. 


In  addition,  if  overlays  are  used  in  the  Keyword 
Processor,  the  following  is  also  added: 


0_  7 _ 17  IS  35 

ioc*  I ~ _'V,  ] " L 

* Over  lay  Count 


In  addition,  the  following  three  words  are  added 
for  EACH  overlay: 


17  18 

35 

OVERLAY  ■ r ‘ 

1 

NAME 

1 

m’bz  I 

MBZ 

1 

mbz  I 

MBZ 

1 

Keyword  Processor  Profile  at  Execution  Time 


During  i ni  t ial  izat  ion  tire  Keyword  Processors  ate 
GECALLed  by  the  Executive  using  the 
Keywor d-Pt ocessor -ID  and  written  out  to  the  $L  Load-. 
The  Load-File  block  address,  Keyword  Processor  size  in 
64-word  blocks  and  entry  address  are  filled  in  dur  ing 
this  process.  If  the  assembled  Keyword  Processor 
Pro!  lie  is  unacceptable  or  the  Keyword  Processor  cannot 
be  written  to  the  Load-File,  the  second  word  of  the 
profile  is  set  to  zero. 
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0 

17  18 

26  27  29  30 

35 

1 

NOT  USED 

1 KEYWORD 

-PROCESSOR-ID 

1 

To 

1 

TLOAD-FILE  BLOCK  ADDRESS 
1 

1 KEYWORD 
1 SIZE 

PROCESSO'R  FMBZ 

1 

1 

1 

1 

ENTRY  ADDRESS 

1 PTR  TO 

FIRST  KEYWORD 

1 

1 

1 

DEFAULT  PRIORITY 

1 FLAGS 
1 

1 # NEW  TASKS 
1 IN  CORE-Q 

1 

1 

If  the  Keyword  Processor  contains  overlays,  they 
are  GECALL'd  by  the  Executive  using  the  overlay  name(s) 
and  written  out  to  the  $ L Load-File.  The  Load-File 
block  address  on  the  $ L Load-File,  overlay  entry 
address,  origin  and  size  are  written  in  the  Overlay 
entry.  Each  overlay  entry  then  contains  the  following: 


0 

17  18 

35 

1 OVERLAY 

1 NAME 

1 

1 ORIGIN 

1 SIZE  (In  Words) 

1 

1 ENTRY  ADDRESS 

r STARTING  BLOCK  * 

1 

Keywords  List 


The  Keywords  List  is  generated  by  the 
Processor  Profile  macro.  Keywords  for  all  the 
Processors  form  a contiguous  table  since  the 
location  counter  is  dedicated  to  the  list  and 
by  the  .PRFL.  macro.  The  format  for  an  entry 
Keywords  List  is  as  follows: 


Keyword 
Keyword 
. .KEYL 
invoked 
in  the 


0 17  18 IS 

1 KEYWORD  (BCD  CHARACTERS  0-5)  ' ' I 

j _L 

IKEYWOR'd  (BCD  CHARACTERS  6-7)  I 

J L 

I PTR  TO  KEYWORD  PROCESSOR  I USAGE  COUNT  I 

I PROFILE J I 

H^YWOR'D  “PR'IORITY  I BYPASS  COUNT  T 


The  usage  count  represents  the  number  of  transactions 
received  that  designated  the  related  keyword. 
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QUEUES 


Queues  are  required  by  the  system  functions  when 
their  initiation  would  be  untimely  and  must  be  delayed 
or  when  they  are  unable  to  provide  or  complete  their 
f unct ion . 


Criteria  for  queue  assignment  to  individual  system 
functions  includes  the  need  for  a particular 
queue-entry  format  and/or  the  need  for  optimized  or 
specialized  queue  mechanics.  As  a result  some  system 
modules  have  their  own  queue,  such  as  the  Core 
Allocator's  Core-Queue,  while  other  modules  do  not, 
such  as  the  TASK  Terminator. 


The  necessary  queues  for  the  latter  functions  are 
combined  as  logical  sub-queues  into  one  physical  queue. 
Such  IS  the  case  with  the  Dispatcher ' s-Queue . This 
queue  not  only  holds  TASKS  waiting  for  processor 
assignment,  but  also  those  TASKs  requiring  termination 
and  selected  fault  requested  system  services. 


Core-Queue 


The  Core-Queue  links  all  TASKs  awaiting  core 
allocation  in  a forward  and  backward  linked  chain.  The 
TASKS  are  ordered  from  highest  to  lowest  priority 
(.TPRIO  lower)  in  the  forward  (.THEM  upper)  queue 
pointer  direction.  Pointers  to  the  head  and  tail  of  the 
queue  along  with  number  of  TASKs  linked  to  the  queue 
are  contained  in  the  base  of  the  queue  at  cell  .ECOKQ 
in  the  Communication  Region. 

The  Core-Queue  entry  fot  all  TASKs  lesides  within 
the  TASK  itself.  The  general  fornat  for  an  entry  is: 
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0 

17  18  25  26  35 

,TPRIO 

1 BKWD  CORE-QUEUE  PTR 
1 

1 PRIORITY  1 

1 1 

,TMEM 

IFWD  CORE-QUEUE  PTR 
1 

ICORE  IMBZ  1 

1 DEMAND  1 1 

,TLAL 

1 NOT  USED 
1 

1 BYPASS  COUNT  1 

1 1 

where  the  core  demand  is  the  required  core  size  in 
multiples  of  1024-word  blocks. 


It  should  be  pointed  out  that  a TASK  cannot  be 
linked  to  both  the  Core-Queue  and  the 
Dispatcher ' s-Queue , since  TASK  cell  .TPRIO  is  used  in 
both  queue  entries. 


Dispatcher  ' s -Queue 

The  Dispatcher s-Queue  links  all  TASKS  waiting  for 
processor  assignment,  fault  requested  system  services 
or  Executive  administrative  functions  into  a forward 
and  backward  linked  chain.  The  TASKS  are  ordered  from 
highest  to  lowest  priority  (,TPRIO  lower)  in  the 
backward  (,TFLAG  upper)  queue  pointer  direction. 
Pointers  to  the  head  and  tail  of  the  queue  are 
contained  in  the  base  of  the  queue  at  cell  ,EDSPQ  in 
the  Communication  Region, 


Queue  entries  are  embedded  within  the  TASK  they 
represent.  The  general  format  of  an  entry  is: 


,TPRIO 

,TFLAG 


0_ 

i FWD  DSP-QUEUE  PTR  ' 
I 

ThKWD  DSP-QUEUE  PTR 

I _ _ 

TsERVICE  V EC  for 


17  18  35 

I PRIORITY  r 

1 _ I 

rd-SCANNED  status’  FLAGS  T 

_l  _ I 

TaTTRIBUTE  & STATUS  \ 

I FLAGS  I 


TASK  cell  ,TPRI0  must  be  defined  with  an  even 
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1 


offset  so  that  cells  .TPRIO  and  .TFLAG  form  an  even 
word  pair.  This  is  done  to  facilitate  the  queue 
processing  of  the  'Q-scanned  TASK  Status  Flags. 


Output  Intercom-Queue 

All  Intercom  output  messages  waiting  for 
transmission  are  queued  in  priority  sequence  to  form 
the  Output  Intercom-Queue.  Each  queue-entry  describes  a 
complete  output  message,  which  can  consist  of  several 
message  segments;  the  priority  assigned  to  the  message 
and  a pointer  to  the  TASK,  if  any,  associated  with  the 
message . 


The  queue  is  forward  linked  by  message  priority 
and  backward  linked  by  originating  TASK.  Pointers  to 
the  head  and  tail  of  the  queue  are  maintained  in  cell 
.ECQP  in  the  Comunication  Region.  Management  of  the 
available  queue-entry  space  is  accomplished  via  cells 
.ECOMQ.  Queue  entry  format  is: 


0 

17  18 

35 

Tfwd 

1 PTR 

OUTPUT  INTERCOM-Q 

1 PRIORITY 
1 

r 

1 

1 PTR 
1 

TO  FIRST  MSG  SEG 

[not  used 
1 

1 

1 

1 BKWD 
1 PTR 

OUTPUi’  INTERCOM-Q 

1 PTR  TO  ORIGINATING 
ITASK  or  ZERO 

1 

1 
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CORE  & SWAP-FILE  MAPS 


The  Core  and  Swap-File  Maps  are  dynamic  partition 
maps  that  record  usage  by  entry-defined  partitions 
rather  than  static  partition  maps  that  indicate  fixed 
par  t it  ion  usage. 


The  dynamic  nature  of  the  maps  is  enabled  by  using 
forward  and  backward  link  pointers  within  each  map 
entry.  The  link  pointers  thread  the  map  entries  within 
their  assigned  spaces.  The  forward  pointers  link  the 
entries  in  order  of  increasing  partition  origins,  i.e., 
by  core  or  Swap-File  partition  lower  address  limits. 


Each  entry  describes  the  starting  block  address  of 
a core  or  Swap-File  partition  and  the  number  of  free 
blocks  at  the  end  of  the  partition.  The  format  for  the 
general  map  entry  is: 


0 

I FORWARD 'map  POINTER 

I 

1 BACKWARD  MAP  POINTER 


17  18 _ 35 

I # OF  FREE  BLOCKS  a't  THE  | 

I END  OF  THE  PARTITION 1 

'ITARTlffo'N  ORIGIN  T 


The  starting  block  address  for  the  first  free 
block  within  a partition  is  found  by  subtracting  the 
number  of  free  blocks  at  the  end  of  the  partition  from 
the  origin  of  the  next  partition,  which  is  contained  in 
the  succeeding  or  forward  pointed  map  entry. 


Two  special  mao  entries  that  are  not 
usage-defined,  but  assembled  into  the  maps  are  the 
initial  and  final  map  entries.  The  initial  entry  is 
required  to  describe  those  blocks  at  the  beginning  of 
core  or  the  Swap-File  that  do  not  belong  to  a usage 
defined  partition.  The  final  entry  is  necessitated  by 
the  mechanics  of  making  and  releasing  map  entries. 


The  format  for  the  base  map  entries,  which  are 
assembled  adjacent  to  one  another,  is  as  follows: 
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Initial 

Entry 


Final 

Entry 


^ 

r I forward'pointer  to 

I I FIRST  MAP  1NTRY_ 

] IMBZ 

rlMBT 


BACKWARD  POINTER  TO 
I LAST  MAP  ENTRY 


17  18 _ 35 

' I # OF  UNATTACHED  FREE  I 

I BLOCKS _|_ 

I CORE  or  SWAP-FILE  ORIGIN  I 


ICORE  or  SWAP-FILE  UAL 


where  UAL  represents  the  upper  address  limit. 


The  base  map  entries  are  located  in  the 
Executive's  Communication  Region  with  the  symbolic 
tags  : 


. ECMAP  Base  Core-Map  Entries, 
.ESMAP  Base  Swap-File  Map  Entries. 


Cot  e-Map  Particulars 

Entries  for  the  Core-Map  ate  located  within  the 
TASK  defining  the  partition  at  TASK  cells  .TMEM  and 
.TLAL.  Thus  there  is  no  need  to  explicitly  obtain  a 
free  entry  when  making  a new  map  entry. 


The  block  size  used  in  the  Core-Map  is  1024  words. 
Block  addresses  are  always  positioned  within  a word  as 
multiples  of  1024  words. 

The  core  origin  and  UAL  are  determined  during 
initialization  using  cell  31[10]  in  the  Executive's 
Slave  Program  Prefix,  At  this  time  the  Core-Map  base 
entries  are  defined,  so  the  origin  and  UAL  are  merely 
inserted  into  them. 


Swap-File  Map  Particular  s 

A contiguous  block  of  memory  is  reserved  for  the 
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Swap-File  Map  entries  during  assembly  by  the  .SWAP, 
macro.  The  boundaries  of  the  assigned  area  are  recorded 
in  Communication  Region  cell  . ESMAC  by  storing  the 
beginning  map  address  in  the  lower  half  of  .ESMAC  and 
the  last  map  address+1  in  the  upper  half  of  .ESMAC. 


During  execution  free  entries  in  the  map  are 
chained  together  to  avoid  a serial  search  of  the  map 
area  for  an  available  entry.  A pointer  to  the  first 
free  entry  is  maintained  in  .ESMAC  lower. 

The  block  size  used  in  the  Swap-File  Map  is  64 
words.  The  first  available  block  on  the  Swap-File  is 
assumed  to  be  zero. 


At  startup  time  GCOS  is  queried  via  a MME  GEFADD 
to  determine  the  allocated  size  of  the  Swap-File.  The 
number  of  blocks  returned  is  placed  in  the  lower  half 
of  .ESMAP,  as  the  number  of  unattached  blocks  at  the 
start  of  the  file,  and  .ESMAP+3,  as  the  UAL  of  the 
file. 
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INTERCOM  BUFFER  MAPS 


The  purpose  of  the  Input  and  Output  Intercom 
Buffer  Maps  is  to  make  management  of  available  buffer 
space  possible.  To  this  end,  the  maps  describe  buffer 
usage  in  terms  of  partition  pointers  and  available  or 
free  hole  sizes. 


With  two  exceptions,  each  entry  in  the  maps 
specifies  the  available  space  that  follows  a message  or 
message  segment  in  the  buffers.  Thus  the  maps  record 
buffer  usage  by  means  of  message-defined  buffer 
partitions  rather  than  by  usage  of  pre-defined  fixed 
buffer  partitions. 


There  are  two  permanent  map  entries  that  are  not 
usage-defined.  These  are  the  base  map  entry  and  the 
last  map  entry.  The  primary  purpose  of  the  base  map 
entry  is  to  describe  unattached  space  at  the  beginning 
of  the  buffer,  while  the  last  map  entry  is  necessitated 
by  map  mechanics. 

Unlike  the  other  maps  employed,  all  buffer  map 
entries,  except  the  base  map  entries,  reside  within  the 
buffers  at  the  beginning  of  the  partition  they 
describe.  Therefore,  the  location  of  a map  entry  is 
also  the  origin  of  the  partition. 

The  general  format  of  a buffet  map  entry  is: 


0  lZ_i8 35 

1 FORWARD  MAP  LINK  POINTER  ’ ’ " I # OF  FREE  WORDS  AT  THE  | 

I I END  OF  THE  PARTITION  I 

I BACKWARD  MAP  POINTER  ' ’ I MBZ  ’ I 


Both  maps  are  forward  linked  with  backward 
pointers.  Only  the  forward  pointers  are  linked  as  a 
chain.  The  backward  pointers  within  each  entry  point  to 
the  first  word  of  the  previous  entry  and  as  such,  they 
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do  not  form  a linked  chain.  The  only  need  for  the 
backward  pointers  is  to  facilitate  the  reassignment  of 
uuffer  space  to  the  previous  entry  when  the  space  is 
released . 


The  base  and  last  map  entries  along  with  the  size 
of  the  buffers  are  defined  by  the  .BUFF,  macro.  This 
macro  also  reserves  the  requested  amount  of  buffer 
space . 


The  base  map  entries  ate  assembled  into  the 
Communication  Region  with  the  symbolic  tags: 

.EIMAP  Input  Intercom  Buffer  Map, 

. EOMAP  Output  Intercom  Buffer  Map. 

The  format  of  the  base  map  entries  is: 


0 17  18 35 

I LOC  OF  NEXT  TO  LAST  BUFFERl#  OF  UNATTACHED  FREE  WORDSi 
(CELL  I AT  START  OF  BUFFER  I 
ILOC  OF  LAST  BUFFER  CELL  | RESERVED  ' T 


The  lowe 

r half  o 

f the 

f 

irst  base 

entry 

word 

is 

assembled 

as  the 

total 

s iz 

e of  the  buffer  minus  2 

(to 

account 

for  the 

last 

map 

entry, 

which  is 

always 

present) . 

The 

last  map 

entr  y 

is 

assembled 

into  the 

last 

two 

cells  of 

the  buffer 

with 

the 

following 

format: 

0 

17 

18 

35 

1 MBZ  1 

POINTER  TO  BASE  MAP  ENTRY  | RESERVED 


It  should  be  pointed  out  t)iat  the  foiward  map 
pointers  are  always  greater  (addt ess-w Lse)  than  the 
location  of  the  map  entries  in  which  they  lie,  since 
the  map  entries  reside  at  the  beginning  of  the 
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partition  they  describe  and  the  forward  chain 
cot  responds  to  increasing  buffet  addresses. 

The  location  of  the  map  entry  or  the  assigned 
buffer  space,  in  which  an  input  transaction  or  output 
message  lies,  is  kept  in  the  TASK  associated  with  the 
transaction  or  message. 

Buffer  Map  Usage 

For  the  Input  Intercom  Buffer  Map,  entries  are 
released  and  can  be  built  at  the  main-level;  while 
entries  are  built  and  excess  space  is  reassigned  at  the 
courtesy-call  level. 


For  the  Output  Intercom  Buffer  Map,  entries  are 
built  at  the  main-level  and  released  at  the 
courtesy-call  level. 


For  both  maps  the  inaLn-level  code  that  references 
the  maps  must  be  inhibited  to  avoid  link  pointer 
confusion  within  the  maps  in  the  event  an  interrupt  or 
time-runout  occurs.  Since  both  maps  share  the  same 
build  and  release  map  entry  routines,  it  is  necessary 
that  the  routines  be  interrupted. 

Input  Intercom  Buffer 


The  Input  Intercom  Buffet  is  used  for  collection 
of  input  transactions  received  via  Intercom  I/O  from 
TPE. 


Prior  to  issuing  an  Intercom  read  request,  the 
Transaction  Scheduler  scans  the  Input  intercom  Buffer 
Map  to  find  the  smallest  available  hole  in  which  the 
largest  expected  message,  as  determined  from  .EMXSZ, 
will  fit.  If  a hole  is  found,  a new  map  entry  is  built 
to  describe  the  space  and  the  location  of  the  map  entry 
is  recorded  in  cell  .TMSG  of  the  skeleton  TASK,  which 
was  previously  obtained  by  the  scheduler.  A DCW  is 
built  with  a data  address  pointing  to  the  third  word  of 


L. 
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the  available  space,  i.e.,  the  first  word  past  the  map 
entry,  and  the  Intercom  is  issued. 

Upon  completion  of  the  I/O,  the  space  description 
for  the  partition  into  which  the  input  message  was 
read,  is  adjusted  to  reflect  the  actual  size  of  the 
message  as  determined  from  the  data  address  reside  in 
the  second  Status  Return  word.  The  actual  message  size 
is  also  placed  in  cell  .TMSG  of  the  skeleton  TASK 
allocated  for  this  transaction. 


After  a Keyword  Processor  has  requested  the 
transaction  via  a trapped  MME,  the  tr ansact ion-def ined 
buffer  partition  is  released  by  combini.ig  it  with  the 
available  space  of  the  previous  (lower  address)  or 
backward  pointed  partition  and  the  mao  entry  is 
unlinked . 


Output  Intercom  Buffer 


The  Output  Intercom  Buffer  is  used  for  collection 
and  Intercom  buffering  of  output  message  segments 
destined  for  TPE.  Since  message  segments  with  different 
transaction  numbers  cannot  be  intermixed  when  sent  to 
TPE,  all  segments  for  each  transaction  must  be 
collected  and  linked  together  in  the  Output  intercom 
Buffer,  until  an  End-o f-Message  or  End-Of-Tr ansact ion 
status  is  detected.  At  this  time,  an  Output 
Intercom-Queue  entry  is  obtained  and  built  for  the 
message.  The  Output  Intercom  Processor  will  issue 
successive  Intercom  writes  to  pass  the  message  segments 
to  TPE. 


Message  segments  are  threaded  by  transaction 
number  within  the  Output  Intercom  Buffer  by  placing  a 
linkage  word  in  the  first  word  of  each  message  segment. 
The  linkage  format  is; 


0 17  J.8  _ _ _ .35 

(POINTER  TO  NEXT  SEGMENT  for'  I SIZ'e 'of  'this  SEGMENT  IN  ‘ T 
(THIS  MESSAGE  or  ZERO  (WORDS  ( 
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The  beginning  anfl  ending  addresses  of  each  thread 
ate  recorded  in  TASK  cells  . TMSG  and  .TMSG2  of  the 
generating  Keyword  Processor's  TASK, 


Buffet  Threshold  Entries 


At  initialization,  a portion  of  the  available 
memory  for  the  buffers  is  set  aside  to  serve  as  a 
threshold  area.  Should  the  reduced  buffers  not  have 
enough  space  for  additional  messages,  TPOS  will  attempt 
to  grant  an  additional  1024-word  block  of  memory  to  the 
buffer.  Since  the  memory  (which  must  be  contiguous  to 
the  buffer  area)  may  be  in  use,  the  threshold  area  will 
be  used  to  serve  as  an  immediate  and  temporary  relief 
until  the  full  1024  words  can  be  obtained.  See  the 
illustration  on  the  following  page. 
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KEYWORD  PREFIX  AREA 


The  Keyword  Prefix 
Pxocessor  is  analogous  to 
(SPA)  of  a TPAP.  This 
execute  within  the  Executive 
with  no  special  restrictions. 


Area  (KPA)  of  a Keyword 
the  Slave  Program  Prefix 
arrangement  allows  a TPAP  to 
as  a Keyword  Processor 


The  KPA  is  intended  to  be  the  common  communication 
area  between  the  Executive  and  the  Keyword  Processor 
analogous  to  the  SPA,  It  is  also  used  to  hold 
transaction  related  information  whenever  the  Keyword 
Processor  is  not  in  execution.  For  example,  the  DCWs 
used  for  a core-load  or  swap-out  are  built  in  the  KPA; 
also  the  processor  register  values  are  safe-stored  in 
the  KPA  whenever  the  Keyword  Processor  is  taken  out  of 
execution  by  the  Executive. 


No  control  information  can  be  stored  in  the  prefix 
when  its  GELBAR  is  in  effect,  since  the  KPA  is  within 
the  GELBAR  boundaries  of  its  associated  Keyword 
Processor . 


SPA  Cells  Suppor  ted  as  KPA 

Cer tain  SPA  cells  supported  by  GCOS  ate  not  supported 
by  the  Executive  because  the  cells  may  only  be 
necessary  for  GCOS  administrative  functions  or  MME 
functions  which  are  inappropriate,  disallowed  or 
legitimate  but  not  incot por ated . 


Keyword  Processor  fault  vectoi s are  fully 
supported.  The  only  other  KPA  cell  that  is  directly 
supported  is  the  equivalent  of  the  GELOAD  limits,  i.e., 
cell  11  I 10).  The  latter  cell  is  set  after  a Keyword 
Processor  core-load  in  case  ,SETU  is  not  attached  and 
the  load  limits  are  used. 


The  lower  load  limit  is  developed  as 
Processor  size  in  TASK  cell  .TSWAP  lowe 
size  as  symbolically  equated  to  .EPRFX. 
next  available  lower  address.  The  upper 


the  Keyword 
r plus  the  KPA 
That  is  the 
load  limit  is 
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set  to  the  assigned  core-size  minus  one,  where  the 
core-size  was  saved  in  .TPAD  lower  during  the 
core-load.  If  the  lower  limit  is  greater  than  the  upper 
limit,  it  is  set  to  the  latter. 
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Executive  Module  & Routine  Desct ipt ions 

An  overview  of  the  major  Executive  modules  along 
with  the  descriptions  of  each  module's  component 
routines  are  on  the  following  pages.  In  order  to 
simplify  and  standarize  the  routine  descriptions,  the 
notation  below  was  used: 


EPn  - Entry  Point  n 

RRn  - Routine  Return  n 

This  type  of  return  passes  or  returns  control 
back  to  the  calling  routine. 

RTn  - Routine  Transfer  n 

This  type  of  return  passes  control  to  a 
predetermined  routine. 

CPn  - Calling  Parameter  n 

RPn  - Return  Parameter  n 

L(  ) - Location  of 

Call  - Location  or  IC  from  which  the  call  to  a 
routine  was  made. 


L 
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GELBAR  Fault  Handler 


When  interrupts  and  faults  occur  while  a GELBAR  is 
in  effect,  GCOS  passes  control  to  the  Executive  Fault 
Handler  via  the  GELBAR  fault  vector  located  in  cell 
19[10)  of  the  Executive's  SPA.  Faults  occuring  outside 
of  a GELBAR  are  not  processed  by  this  handler. 


The  major  functions  of  the  GELBAR  Fault  Handler, 
when  given  control  by  GCOS,  aie  to: 


(1)  Safe-store  the  processor  registers,  as  set  by 
the  interrupted  Keyword  Processor,  into  its 
KPA  using  Communication  Region  cell  .ETREG, 

(2)  Safe-store  the  IC  & I and  remaining  GELBAR 
time  in  the  interrupted  Keyword  Processor's 
.TICI  and  .TTIMQ  TASK  cells,  respectively 

(3)  Identify  the  cause  and  type  of  the  fault 
indicated  by  the  GELBAR  Accumulated  Fault 
Status  in  the  Executive's  SPA, 

(4)  Call  the  Dispatcher  to  reissue  the  GELBAR  if 
it  was  broken  by  an  I/O  interrupt, 

(5)  Safe-store  EIS  address  registers  and  pointers 
and  length  registers  into  TASK  areas  . TAR EG 
and  .TEPL  respectively. 

(6)  Pass  control  to  the  applicable  fault 
processing  routine  if  a true  fault. 


If  the  GELBAR  was  broken  by  a true  fault,  the 
elapsed  processor  time  for  the  affected  Keyword 
Processor  is  updated  in  TASK  cell  .TLAPS  and  the 
dispatch  time  remaining  is  saved  in  cell  .TTIMQ. 


Fault  Processing 


Processing  of  all  fault  types  except  a MME  fault, 
is  done  within  the  GELBAR  Fault  Handler  proper. 
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Foi  Lockup  (LUF) , Pai ity  (PAR)  and  Op  Not  Complete 
(ONC)  faults,  the  faulting  TC&I  is  saved  in  cell  10[10] 
of  the  Keyword  Processor  's  KPA  and  abnormal  termination 
of  the  Keyword  Processor  is  initiated. 


For  Divide  Check  (DVC),  Derail  (DRL)  and  Overflow 
(OFL)  faults,  the  faulting  IC&I  is  stored  in  the  first 
word  of  the  applicable  KPA  Fault  Vector.  The  second 
Fault  Vector  cell  is  checked  to  see  if  it  is  zero;  if 
so,  the  Keyword  Processor  is  aborted.  Otherwise  TASK 
cell  .TICI  is  adjusted  to  point  to  the  second  word  of 
the  Fault  Vector  and  the  Dispatcher  is  called  to 
reissue  the  GELBAR  to  the  faulting  Keyword  Processor. 


The  first  occurrence  of  Zero  Op  Code  (ZOP), 
Command  (CMD) , Memory  (MEM)  and  Fault  Tag  (TAG)  faults 
is  treated  identically  tc'  the  previous  group  of  faults 
relative  to  the  applicable  Keyword  Processor  Fault 
Vectors.  However,  the  fact  that  one  of  these  faults  has 
occurred  is  stored  in  the  TASK.  This  is  accomplished  by 
setting  the  B.TFLT  bit  flag  on  in  TASK  cell  .TFLAG. 


Subsequent  ZOP,  CMD,  MEM  or  TAG  faults  will  be 
processed  only  if  the  first  Fault  Vector  cell  has  been 
zeroed  by  the  Keyword  Processor.  This  is  interpreted  to 
mean  that  the  Keyword  Processor  wants  to  process  these 
faults  itself.  Determination  of  whether  this  is  the 
first  fault  occurrence  is  made  by  testing  the  B.TFLT 
bit  flag  in  TASK  cell  .TFLAG  for  an  'on'  state.  If  the 
cell  has  not  been  cleared,  the  Keyword  Processor  is 
abor  ted . 


MME  Ident i f ica t ion/Va lidation 

MME  Identification/Validation  is  a separate 
routine  that  is  grouped  with  the  GELBAR  Fault  Handler. 
Control  passes  to  this  routine  when  the  Accumulated 
Fault  Status  indicates  that  a MME  fault  type  has 
occurred.  This  routine  first  identifies  the  requested 
MMF  service  by  examininq  the  upper  half  of  the  Keyword 
Processor's  MME  instruction.  If  the  address  is  legal 
and  specifies  an  MME  function  that  has  been 
incorporated  into  the  Executive,  control  is  passed  to 
the  appropriate  MME  processing  routine.  Otherwise  the 
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Keyword  Processor  is  aborted. 


ORL  Identification/Validation 


DRL  Ident if ication/Validation  is  a separate 
routine  that  is  grouped  with  the  GELBAR  Fault  Handler. 
Control  passes  to  this  routine  when  the  Accumulated 
Fault  Status  indicates  that  a DRL  fault  type  has 
occurred.  This  routine  first  identifies  the  requested 
DRL  service  by  examining  the  upper  half  of  the  Keyword 
Processor's  DRL  instruction.  if  the  address  is  legal 
and  specifies  a DRL  function  that  has  been  incorporated 
into  the  Executive,  control  is  passed  to  the 
appropriate  DRL  processing  routine.  Otherwise  the 
Keyword  Processor  is  aborted. 


GELBAR  Fault  Handler 


FUNCTION: 

This  routine  serves  the  Executive  by  identifying 
the  reason  for  a broken  GELBAR  and  routing  control 
to  the  appropriate  fault  processing  routine.  The 
elapsed  processor  time  for  the  affected  Keyword 
Processor  is  updated  if  a true  fault  occurred. 


ENTRIES: 

EP  - GELBAR  Fault  Handler  (FLTOOO). 

Control  is  passed  to  this  entry  point  via  the 
GELBAR  Fault  Vectors  (located  in  word  19[10]  of 
the  Executive's  SPA)  by  GCOS. 

No  calling  parameters. 


RETURNS : 

Control  IS  routed  to  the  applicable  fault 

processing  routine  according  to  the  fault  type 
within  the  GELBAR  accumulated  Fault  Status 

(located  in  word  25(10)  of  the  Executive's  SPA). 
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GELBAR  MME  Validation 


FUNCTION : 


This  loutine  identifies  and  validates  the 
requested  MME  par amete;  within  the  faulting 
Keyword  Processor.  If  the  parameter  is  illegal  or 
restricted,  the  Keyword  Processor  is  marked  for 
abort  with  the  appropriate  error  code  stored  in 
the  TASK.  If  the  parameter  is  legal,  control  is 
passed  to  the  requested  MME  processing  routine  via 
a MME  vector  table. 


ENTRIES : 


EPl  - GELBAR  Non-returnable  control  passes  to  this 
routine  exclusively  from  the  GELBAR  Fault 
Handler . 

CPI  - L (TASK)  associated  with  the  faulting 
Keyword  Processor. 


RETURNS: 


RTl  - D ispatcher  ' s-Queue  Service 

If  an  illegal  or  restricted  MME  parameter. 
RT2  - Applicable  MME  Routine. 

If  a legal  MME  parameter  . 

RPl  - L (TASK)  requesting  MME  service. 
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Transaction  Scheduler 


Function 


The  Transaction  Scheduler  is  responsible  for 
managing  transaction  input,  validating  Keywords  and 
queueing  new  transaction  processing  requests  for  the 
Core  Allocator. 


The  scheduler  and  main-body  of  the  Executive 
execute  virtually  independent  of  one  another. 
Consequently,  they  must  interface  to  communicate  new 
transaction  processing  requests.  The  interface  is  the 
Core-Queue,  with  each  processing  request  identified  by 
Its  assigned  TASK. 


Introduction 


The  scheduler  is  initially  enabled  by  the 
Dispatcher  at  the  main-level.  An  Intercom  read  to  TPE 
is  issued  at  the  main-level  for  the  first  transaction, 
after  which  control  is  returned  to  the  Dispatcher.  From 
this  point  on  the  scheduler's  processing  is  essentially 
courtesy-call  driven.  That  is,  when  a transaction  is 
passed  to  the  Executive  and  the  Intercom  courtesy-call 
is  paid,  a subsequent  Intercom  read  for  the  next 
transaction  is  issued  within  the  courtesy-call  to 
maintain  GCOS  dispatches  directly  to  the  scheduler  at 
the  courtesy-call  level.  in  this  context,  the 
Transaction  Scheduler  and  the  remainder  of  the 
Executive  run  asynchronously. 

The  scheduler  can  be  forced  to  disable  itself. 
This  occurs  when  internal  conditions  make  it  impossible 
tor  the  scheduler  to  issue  an  Intercom  read,  in  this 
case  it  must  terminate  its  courtesy-call  without  an 
outstanding  Intercom  read  request  and,  consequently, 
the  scheduler's  courtesy-call  processing  is  also 
terminated.  When  this  occurs,  the  Transaction  Scheduler 
IS  said  to  have  ' stal led-out . 


The  Dispatcher  periodically  enables  the  scheduler 
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at  the  main-level,  regardless  of  whether  the  scheduler 
is  functioning  normally  at  the  courtesy-call  level  or 
IS  stalled-out.  The  scheduler  uses  the  enable  in  an 
attempt  to  restart  itself  in  the  event  it  is  stalled; 
otherwise,  it  ignores  the  enable  by  immediately 
returning  control  to  the  Dispatcher. 


Stall-Out 


The  scheduler  is  forced  to  explicitly  'remember' 
where  it  stalls-out,  because  it  cannot  relinquish 
control.  If  enabled  at  the  main-level,  it  must  return 
control  to  the  Dispatcher  so  that  any  other  remaining 
Executive  processing  can  be  acted  on.  If  enabled  within 
courtesy-call,  a relinquish  is  not  allowed.  As  a 
result,  the  scheduler  cannot  implicitly  suspend  itself; 
it  must  terminate  itself. 


The  scheduler  stores  its  IC&I  in  Communication 
Region  cell  .ESTAL,  the  stalled  Scheduler  Vector, 
everytime  it  enters  a phase  of  Intercom  read  initiation 
which  it  may  not  be  able  to  successfully  complete.  If 
It  stalls-out,  .ESTAL  will  point  to  the  phase  where  the 
scheduler  should  be  restarted.  if  the  scheduler 
successfully  passes  a problem  phase,  it  retains  the 
accumulated  controls  in  case  it  stalls-out  later.  When 
the  scheduler  successfully  completes  all  phases,  .ESTAL 
is  zeroed  and  rhp  read  can  be  issued. 


Vv’hen  the  scheduler  is  enabled  by  the  Dispatcher  at 
the  main-level,  it  examines  .ESTAL  to  see  if  it  is 
zero.  If  so  the  scheduler  returns  control  and  thus 
ignores  the  enable.  Otherwise,  it  attempts  to  restart 
Itself  by  transferring  control  to  the  ICirl  previously 
saved  in  .ESTAL.  Successful  or  not,  the  scheduler 
returns  control  to  the  Dispatcher  after  tlie  restart 
attempt . 


Intercom  Read  Initation 


The  Transaction  Scheduler  must  obtain  sufficient 
input  buffer  space  and  an  unassiqned  TASK  prior  to 
issuing  an  Intercom  read  to  TPE  for  the  first  or 
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subsequent  input  messages. 


The  amount  of  input  buffer  space  required  for  a 
new  message  is  always  presumed  to  be  the  size  of  the 
largest  possible  input  message,  as  recorded  in 
Communication  Region  cell  .EMXSZ.  The  necessary  buffer 
space  is  obtained  by  searching  the  input  buffer  space 
map,  based  at  .EIMAP,  for  a buffer  hole  in  which  the 
largest  possible  message  can  fit.  The  scheduler  stalls 
if  sufficient  space  cannot  be  found,  otherwise,  a 
buffer  map  entry  is  built  for  the  allocated  space  and 
the  location  is  stored  to  prevent  its  loss  in  an 
ensuing  stall-out. 


An  attempt  to  get  an  unassigned  TASK  is  made  once 
buffer  space  has  been  obtained.  The  TASK  Space 
management  cells  at  .ETASK  are  queried  to  determine  if 
an  available  TASK  exists.  If  none  is  available,  the 
schedule  stalls  out;  otherwise,  a skeleton  TASK  is 
built  in  the  assigned  space  and  the  location  of  the 
previously  obtained  input  buffer  space  is  saved  in  TASK 
cell  .TMSG.  An  Intercom  read  can  now  be  initiated  with 
a courtesy-call  pointer  to  the  Intercom  read 
termination  routine. 


Intercom  Read  Termination 


When  the  courtesy-call  is  paid,  the  Intercom  I/O 
Status  Return  is  first  checked.  The  intercom  read  is 
reissued  if  a lost  interrupt  was  returned;  otherwise, 
the  new  transaction's  keyword  is  extracted  and 
validated.  This  is  accomplished  by  trying  to  match  the 
keyword  against  the  Keywords  List,  which  is  based  in 
communication  cell  .EKEYL.  If  no  match  exists,  the 
transaction  proper  is  discarded  by  eliminating  all 
references  in  the  assigned  TASK  to  the  buffer  space  in 
which  the  message  lies.  This  is  done  so  that  the  space 
can  be  used  for  the  next  Intercom  read.  The  TASK 
assigned  to  the  erroneous  messages  is  then  linked  to 
the  Dispatcher ' s-Queue  and  flagged  for  abort.  This  will 
cause  the  appropraite  error  message  to  be  returned  to 
the  user . 
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If  a match  is  found,  the  input  buffer  space 
assigned  to  the  new  message  is  adjusted  to  reflect  the 
actual  message  size  as  determined  from  the  data  address 
residue  in  the  Status  Return.  The  priority  associated 
with  the  matching  keyword  in  the  Keywords  List  is 
assigned  to  the  transaction  via  its  TASK  and  the 
Keyword  Processor  Profile  is  located.  Selected  profile 
information  is  also  copied  to  the  TASK. 


The  scheduler  then  calls  the'  Core  Allocator  to 
link  the  new  transaction's  core  demand  to  the 
Core-Queue.  Depending  on  the  return  taken  by  the  link 
routine,  an  optional  attempt  can  be  made  to  allocate 
core  to  the  TASK  designated  Keyword  Processor  within 
the  courtesy-call. 


At  this  point  the  scheduler  has  finished  its 
processing  of  the  new  transaction.  Notice  that  either 
the  assigned  TASK  has  been  linked  to  the  Core-Queue  or 
the  core-load  of  the  designated  Keyword  Processor  has 
been  initiated.  Thus  the  new  transaction  processing 
request  has  been  passed  on  to  the  Executive's 
ma in-body . 


The  Intercom  read  termination  then  calls  the  Intercom 
initiation  routine  to  attempt  to  start  the  next  input 
request.  Successful  or  not,  control  is  returned  and  the 
courtesy-call  is  terminated.  If  the  initiation  routine 
stalled-out,  it  will  try  to  restart  itself  at  the 
main-level  when  the  Dispatcher  enables  it. 
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'ft  ansaction  Schedulet  Entry  Points 

Symbol  Title 

SCHlOO  Initiate  Intercom  Read 

SCHllO  Initiate  Input  Within  Courtesy-Call 

SCH120  Initiate  Input  Within  Courtesy-Call 

With  Buffer  Space 
SCHllO  Reissue  Intercom  Read 

SCH200  Input  Intercom  Courtesy-Call 

SCH400  Get  & Build  Skeleton  TASK 

SCH500  Get  Profile  Specifics 

SCH510  Get  Profile  Specifics  Given  Keyword 
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Initiate  Intet  com  R^ad 
FUNCTION: 


This  routine  obtains  input  buffer  space  for  the 
largest  input  message  the  Executive  can  handle, 
builds  a skeleton  TASK,  and  issues  an  Intercom 
r ead  to  TPE . 


ENTRIES: 


EPl  - Initiate  Intercom  Read  (SCHlOO) . 

EP2  - Initiate  Input  within  CC  (SCHllO), 

This  entry  is  called  by  the  Input  Intercom  CC 
routine  to  drive  the  Transaction  Scheduler  at 
the  coui tesy-call-level . 

EPl  - Initiate  Input  within  CC  with  Buffer  Space 
(SCH120) . 

This  entry  is  called  by  the  Input  Intercom  CC 
routine  when  the  previous  message  was  in 
error  and  the  buffer  space  can  be  reused. 

CPl  - Pointer  to  input  buffer  map  entry+2. 

EP4  - Reissue  Intercom  Read  (SCHllO). 


RETURNS : 


Return  is  made  to  the  Call+1.  If  input  buffer 
space  or  a free  TASK  cannot  be  found,  the 
Transaction  Scheduler  is  marked  as  being  stalled 
by  placing  the  ICt«I  in  .ESTAL. 
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Input  Intercom  CC 


FUNCTION: 


This  routine  is  the  cour tesy-cal 1 serviced  by  GCOS 
at  completion  of  the  Transaction  Scheduler's  input 
Intercom.  Transaction  related  information  is 
inserted  into  the  skeleton  TASK,  the  keyword  is 
isolated  and  the  Executive's  Keyword  List  is 
scanned  for  a match  to  locate  the  associated 
Keyword  Profile.  If  a match  is  found,  Keyword 
Profile  specifics  are  copied  into  the  TASK,  excess 
buffer  space  is  reassigned,  the  new  TASK  is  linked 
to  the  Core-Q  with  a possible  attempt  at  core 
allocation,  and  intercom  input  is  initiated  to 
receive  the  next  message  queued  by  TPE.  If  a match 
cannot  be  found,  input  buffer  space  is  reassigned 
from  the  TASK,  the  TASK  is  marked  for  abort  with 
the  appropriate  error  code,  and  Intercom  input  is 
initiated  using  the  reassigned  input  buffer  space. 


ENTRIES: 


EPl  - Input  Intercom  CC  (SCH200) . 

This  entry  is  driven  by  courtesy-call. 


RETURNS: 


Return  is  made  to  GCOS  via  a MME  GEENDC. 
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Get  and  Build  Skeleton  TASK 
FUNCTION: 

This  routine  attempts  to  obtain  a free  TASK.  If 
one  is  found,  the  TASK  is  cleared  to  zeros  and  a 
Transfer-Set-Index  instruction  is  stored  as  the 
Courtesy-Call  Vector  in  cell  .TCCV  of  the  skeleton 
TASK.  In  addition  TASK  stack  cells  .TPUSH,  .TPOP 
and  .TALLY  are  initialized. 

ENTRIES: 

EPl  - Get  and  Build  Skeleton  TASK  (SCH400)  . 

No  calling  parameters. 

RETURNS : 

RRl  - Call+1,  Free  TASK  not  available. 

RR2  - Call+2,  Skeleton  TASK  built. 
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Seal ch  Keywords  List 
FUNCTION: 

This  routine  searches  the  Executive's  Keywords 
List  to  find  a match  with  the  designated  keyword. 

ENTRIES: 

EPl  - Search  Keyword  List  (SCH410) . 

CPl  - Keyword  to  be  matched. 

RETURNS: 

RRl  - Call+1,  No-match. 

RR2  - Call+2,  Keyword  match  found. 

RPl  - Pointer  to  matching  entry  in  the  Keywords 
List . 
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Get  Pi  of  He  ^oc^ics 
FUNCTION: 


This  routine  searches  the  Executive's  Keyword  List 
given  a message  keyword,  if  a match  is  found,  the 
keywoi d usage  count  is  updated,  the  Keyword 
Profile  is  located  and  profile  specifics  are 
inserteo  into  the  TASK.  If  no  match  is  found  or 
the  requested  Keyword  Pr ocessor  could  not  be 
properly  initialized  during  startup,  the  TASK  is 
linked  to  the  Dispatcher ' s-Q  for  abort  with  the 
appropriate  error  code  inserted  in  the  TASK. 


ENTRIES: 


Common  calling  parameters  are: 


CPI 

- L(TASK) . 

CP2 

- (input  message) 

EPl 

- Get 

Profile  Specifics 

EP2 

- Get 

Profile  Specifics 

CP3 

- Keyword. 

(SCH500) . 
given  Keyword 


(SCH510) . 


RETURNS: 


RRl  - Call+1,  No  keyword  match. 
RR2  - Call+2,  Successful. 
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Introduction 


The  Coie  Allocatoi  is  responsible  for  managing 
available  core  and  TASK  core  demands,  assigning  core  to 
requesting  TASK  on  a priority  basis  and  loading  and/or 
swapping  the  applicable  Keyword  Processors  into  core. 
The  major  design  objective  for  the  Core  Allocator  is  to 
maximize  the  use  of  assigned  core  space  while 
preserving  the  priority  structure  of  the  Executive. 

Concept  & Definition 

Allocation  means  the  assignment  of  a selected 
available  resource  to  a selected  resource  demand.  The 
allocation  algorithum  must  specify  the  demand/resource 
order  and  the  selection  method  for  both  the  demand  and 
the  available  resource. 

Core  allocation  within  the  Executive  can  assume 
one  of  two  basic  forms.  Depending  on  whether  the  demand 
or  resource  is  selected  first,  the  form  is  either: 

1.  a specific  (selected)  demand  is  effectively 
matched  against  all  available  core  resources, 
or 

2.  a specific  available  core  resource  is 
effectively  matched  against  all  current 
demands . 

In  both  forms  the  matching  process  is  synonymous  with  a 
selection  method. 

The  first  form  of  allocation  is  called  'demand'  or 
'load'  allocation  since  it  results  in  the  simple  load 
of  a Keyword  Processor.  The  second  form  is  called 
'available  resource'  allocation.  It  is  also  called 
'swap  resource'  or  just  'swap'  allocation  when  it 
results  in  a Keyword  Processor  swap-out. 
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Independent  of  the  type  of  allocation  employed, 
the  sets  of  cuiient  demands  and  available  resources  c.re 
cataloged  into  the  Core-Queue  and  Core-Map 
respectively.  Demand/r esour ce  selection  is  effectively 
made  from  these  sets. 


Cor  e-Map;  The  Resource 


All  TASKS  that  have  been  assigned  core  space  ate 
linked  together  via  their  .THEM  and  .TLAL  cells  to  form 
the  Core-Map.  Each  entry  ir>  the  map  specifies  the  lower 
address  limit  (LAL)  of  its  associated  core  partition 
along  with  the  size  of  any  unused  core  space  at  the  end 
or  bottom  of  the  partition.  Cote-Map  entries  ate 
ordered  in  ascending  sequence  by  the  LAL  of  the  core 
space  they  describe  when  following  the  pointers  in 
.THEM  (called  the  forward  direction). 


The  Cote-Map  is  a dynamic  partition  map  since  the 
number  of  map  entr ies  and  the  sizes  of  the  pat  titions 
they  define  are  variable.  Because  of  this  dynamic 
nature,  the  first  and  last  entries  ate  pre-defined  by 
assembling  them  into  the  'base'  of  the  Cor e-Map  at 
Communicat ion  Region  cell  .ECMAP.  The  first  base  map 
entry  describes  the  free  core-hole  (if  any)  at  the 
start  of  assigned  cote.  The  last  base  map  entry  is  a 
dummy . 

The  unused  core  spaces  (holes)  at  the  end  of  the 
dynamic  partitions  represent  available  core  resources, 
core-spaces  assigned  to  swap-eligible  TASKS  are  also 
considered  to  be  available  resources.  However  , these 
resources  are  peculiar  in  that  the  spaces  are  not 
reflected  as  free  holes  in  the  Cote-Map  for  priority 
reasons.  They  ate  called  'swap'  resources  so  that  they 
can  be  differentiated  from  the  normal  free-hole 
resource.  the  Dispatcher ' s-Queue  is  scanned  for 
swap-eligible  TASKs  when  it  is  necessary  to  locate  and 
examine  this  special  resource. 
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Cof  e-Queue ; The  Demand 


All  TASKS  awaiting  cote  allocation  ate  linked 
together  via  their  .TPRIO  and  .TMEM  cells  to  form  the 
Core-Queue.  A queue-entry  consists  of  cells  .TPRIO, 
.TMEM  and  .TLAL  from  each  linked  TASK.  Each  entry  in 
the  queue  specifies  the  priority  of  the  demand 
(.TPRIO),  the  required  core  size  for  the  Keyword 
Processor  designated  by  the  TASK  (.TMEM)  and  an 
allocation  bypass  count  (.TLAL),  which  is  explained 
later.  The  queue  entries  are  linked  by  demand  priority 
such  that  the  priority  sequence  is  descending  when 
following  the  thread  pointers  in  .TMEM  (called  the 
forward  direction)  and  ascending  when  following  the 
thread  pointers  in  .TPRIO  (called  the  backward 
direction) . 


During  certain  phases  of  allocation  it  is 
necessary  to  know  the  logical  Q-index  of  tie  Core-Queue 
entries  so  that  an  explicit  comparison  of  their  orders 
can  be  made.  The  logical  Q-index  of  an  entry  is  its 
position  within  the  Cor e-Queue  relative  to  the  forward 
queue  pointers.  Tuis  is  an  implicit  relationship  since 
the  chosen  queue  construction  means  the  queue  entries 
are  threaded  together  by  link  pointers  to  form  the 
queue.  The  logical  Q-index  is  found  by  counting  the 
number  of  entries  linked  from  the  base  of  the 
Core-Queue  (.ECORQ)  up  through  the  entry  in  question, 
in  the  forward  direction.  Because  of  the  method  used  to 
determine  the  logical  Q-index  of  an  entry,  it  is 
alternately  called  the  entry's  'Q-depth*. 


Resource  Selection 


Resource  selection  is  the  selection  of  an 
available  core  resource  from  the  Core-Map  or  a swap 
resource  from  the  Dispatcher  ' s-Queue.  The  criteria  for 
resource  selection  is  dependent  upon  the 
demand/resource  selection  order.  For  demand  allocation, 
resource  selection  is  'best-fit',  i.e.,  the  selected 
available  core  resource  is  the  smallest  available  that 
satisfies  the  selected  demand.  For  resource  allocation 
the  selection  method  is  circumstantial.  This  is  best 
exhibited  when  the  available  resource  is  to  be  created 
by  swapping-out  an  in-core  Keyword  Processor  and 
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combining  the  adjacent  coi e holes  (if  any)  with  the 
swap-fieed  coie.  In  this  case  the  resouice  is 
implicitly  selected  accoiding  to  the  swap-eligibility 
of  some  Keywoid  Piocessor. 


Demand  Selection ; Bypass/No-pass  Logic 


Demand  Selection  is  the  selection  of  a particular 
core  demand  from  the  Cote-Queue.  It  is  a design 
objective  to  make  demand  selection  priority  dependent. 


since  the  Core-Queue  observes  priorities,  i.e., 
its  entries  are  priority  linked  to  the  queue,  priority 
demand  selection  simply  results  in  the  sequential 
selection  of  demands,  starting  with  the  high  priority 
tail  of  the  queue.  Rigid  adherence  to  such  a selection 
method  would  result  in  a pre-emptive  allocation 
procedure.  This  is  undesirable  because  poor  core 
utilization  is  a likely  side  effect. 


Bypass  logic  is  employed  in  demand  selection  to 
allow  the  Core  allocator  to  pass  over  large  cote  demand 
TASKS  within  the  Cote-Queue  for  which  it  is  unable  to 
find  sufficient  cote,  and  to  assign  cote  to  smaller 
demand,  lower  priority  TASKS. 


Though  bypass  logic  is  a batching  principle  in 
that  it  attempts  to  maximize  resource  utilization  and 
throughput,  its  necessity  in  a compromised  interactive 
environment  with  limited  resources  is  deemed  both 
reasonable  and  necessary. 


Negating  bypass  logic  is  no-pass  logic.  This  is 
required  to  ensure  that  the  high  core  demand  TASK  will 
eventually  be  brought  into  core.  Eypass/no-pass 
decisions  depend  on  the  bypass  count  assigned  to  a TASK 
and  consequently  its  Core-Queue  entry  when  it  is  linked 
to  the  queue.  This  count  is  presently  obtained  from  the 
demand  associated  Keyword  Processor  Profile. 


The  bypass  count  represents  the  number  of  times  a 
TASK  can  be  passed  over  by  the  Core  Allocator  before  it 
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stops  the  Allocator  from  selecting  lower  priority 
demands.  This  count  is  decremented  by  one  every  time 
core  is  allocated  to  a lower  priority  demand  in  the 
Core-Queue  until  the  bypass  count  has  runout,  A TASK  or 
Core-Queue  entry  whose  bypass  count  has  runout  (is 
zero)  is  called  a no-pass  since  it  is  logically  treated 
as  the  end  of  the  queue.  A no-pass  remains  until  it  is 
allocated  its  required  core. 

It  is  possible  for  mote  than  one  no-pass  to  be 
present  in  the  Core-Queue  at  the  same  time.  For  this 
reason  no-pass  TASKS  are  linked  together  in  descending 
priority  sequence  via  the  .TRAD  cell  within  the  no-pass 
TASKS.  A pointer  to  the  highest  priority  no-pass  TASK 
along  with  its  Core-Queue  depth  is  maintained  in  the 
Executive  Communication  Region  cell  .ENPQD. 


Bypass/no-pass  logic  does  not  alter  the  sequential 
demand  selection,  it  only  conditions  the  priority 
nature  of  selection  so  that  it  is  possible  to  'go 
around'  a demand  that  can't  be  satisfied,  rather  than 
having  to  stop.  It  is  worth  noting  that  by  setting  all 
bypass  counts  to  zero  the  bypass/no-pass  logic  is 
functionally  desengaged,  thus  restoring  the  Core 
Allocator  to  priority  pre-emptive  demand  selection. 


Normally  when  allocation  is  attempted,  the 
allocator  sifts  the  Core-Queue  up  through  the  highest 
priority  no-pass  entry;  however,  when  a new  demand  is 
linked  to  the  Cote-Queue,  bypass  logic  makes  it 
possible  to  logically  shift  the  queue  by  examining 
certain  allocation  controls  which  are  described  later. 
In  this  case  the  queue  need  not  be  physically  serviced 
since  the  controls  are  sufficient  to  guarantee  that 
allocation  to  the  preceding  old  demands  would  not  be 
possible.  A new  demand  that  is  selected  in  this  manner 
is  termed  'Q-eligible' , 


Demand  Resour  ce  Assignment 


Demand  resource  assignment  consists  of  core-hole 
position  assignment  and  core-hole  assignment  in  that 
order.  Core-hole  position  assignment  refers  to  where  in 
the  selected,  available  core-hole  the  requested  core  is 
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to  be  positioned. 


Foi  demand  allocation  the  selected  resource  is  the 
best  fit  of  all  availables.  However,  even  with  a 
best- fit  it  is  likely  that  the  selected  resource  will 
be  larger  than  the  size  of  the  demand.  In  this  case  the 
demand  is  positioned  at  the  top  of  the  hole  if  the 
Cote-Map  entry  describing  the  available  resource  is  the 
first  base  map  entry  or  lies  in  a TASK  that  is  not 
eligible  for  swap.  If  the  map  entry  lies  in  a TASK  that 
is  eligible  for  swap,  the  demand  is  positioned  at  the 
bottom  of  the  available  core-hole.  This  procedure 
prevents  the  free  core-hole  created  by  a swap-out  from 
becoming  fragmented  since  any  unused  space  in  the 
available  hole  continues  to  be  described  by  the 
previous  map  entry.  Thus  the  demand  is  positioned  at 
the  top  of  the  hole  if  the  previous  (lower  address) 
core  partition  is  not  a 'swapable'  resource,  and  at  the 
bottom  of  the  hole  if  the  previous  is  'swapable'. 


For  swap  resource  allocation,  the  swap  hole  is 
combined  with  the  free  core-holes  above  and  below  it 
and  the  demand  is  positioned  at  the  top  of  the 
resultant  core-hole. 


Core-hole  assignment  is  the  actual  resource  to 
demand  assignment.  This  is  accomplished  by  unlinking 
the  demand  from  the  Core-Queue,  building  a Cote-Map 
entry  to  describe  the  core  partition  being  allocated 
including  any  free  space  below  the  demand,  and  linking 
the  new  entry  (and  the  TASK  in  which  it  lies)  into  the 
Cot  e-Map. 


Cot  e-Map  Anomaly  Put ing  Swap  Resour  ce  Allocation 


Within  the  demand  resource  assignment  phase  of 
swap  resource  allocation,  it  is  desirable  to  position 
the  selected  demand  at  the  top  of  the  swap  hole. 
Because  the  free  hole  above  (lower  address)  the  swap 
hole  proper  could  grow  while  the  swap  hole  is  being 
freed-up,  i.e.,  while  the  Keyword  Processor  occupying 
the  hole  is  being  swapped-out,  actual  resource 
assignment  is  not  made  to  the  demand  until  the  swap 
hole  is  free.  If  the  demand  is  larger  than  the  size  of 
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the  swap  hole  proper, 
free  core-hole  (if 
needed . 


it  is  unclear  how  much  of  the 
any)  below  the  swap  hole  will  be 


This  problem  is  resolved  during  the  initial 
allocation  (before  the  swap  hole  is  freed  up)  by 
combining  the  swap  hole  with  the  free  holes  above  and 
below  it  via  the  Core-Map  entry  describing  the  swap 
hole  and  specifying  that  there  is  no  free  hole  at  the 
end  of  this  partition.  The  map  anomaly  occurs  here 
since  the  size  of  the  combined  core-holes  could  be 
greater  than  demand.  This  means  there  might  be  a free 
hole  of  unknown  size  at  the  end  of  the  partition. 


The  map  anomaly  is  rectified  when  the  swap  hole 
has  been  freed  up  and  true  assignment  can  be  made  to 
the  demand.  At  this  time  the  swap  hole  is  combined  with 
the  free  hole  above  it  (if  any)  and  the  Core-Map  entry 
is  adjusted  to  reflect  the  actual  hole  size  at  the  end 
of  the  partition.  Though  the  free  hole  at  the  bottom  of 
the  partition  is  lost  during  swap-out,  this  method 
ensures  that  the  largest  possible  hole  will  be  created. 


CORE  ALLOCATOR  LOGIC 


Introduction 


The  Core  Allocator  is  a modular  structure 
consisting  of  allocation  routines,  such  as  the 
demand/resource  selection  and  assignment  procedures, 
and  the  necessary  support  routines,  such  as  linking  or 
unlinking  a demand  to  the  Core-Queue,  update  bypass 
counts,  release  core,  mark  cote  eligible  for  swap,  load 
Keyword  Processors  into  core,  etc.  The  allocation 
routines  represent  different  selection  criteria  that 
meet  specific  needs  and  respond  to  key  events,  all  in 
order  to  minimize  response  time  and  allocation 
overhead.  The  support  routines  are  effectively 
independent  of  the  different  allocation  methods  and 
consequently  are  considered  'common'  routines. 


Major  Execution  Pha^s 
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The  Core  Allocator  has  been  designed  to  allocate 
core  and  thus  to  execute  at  main  and  cour tesy-call 
levels.  Main-level  allocation  is  dedicated  to  servicing 
all  demands  in  the  Core-Queue,  up  to  the  highest 
priority  no-pass,  in  priority  order.  Courtesy-call 
allocation  is  dedicated  to  an  event  selected  demand  or 
resource  such  as  a newly  received  demand  or  a free 
core-hole  created  by  a swap-out. 


In  addition  to  multi-level  execution,  the  Core 
Allocator  allows  the  selective  interruption  of 
main-level  allocation  by  courtesy-call  allocation.  This 
is  permitted  so  that  the  Core  Allocator  will  be  as 
responsive  as  posible.  Of  course,  demand  priorities  are 
still  observed. 


Phase  Interruption 

Interruption  creates  procedural  problems  and 
constraints  on  the  allocator's  routines  and  the 
handling  of  the  Core-Queue,  Core-Map  and  control 
information.  In  particular,  common  routines  must  be 
effectively  reentrant;  queue,  map,  and  control 
information  must  be  effectively  gated;  and  the 
courtesy-call  allocations  must  be  interlaced  with  the 
main-level  allocations  so  their  efforts  are  compatible 
and  well-defined. 


The  first  two  problems  are  resolved  by  inhibiting 
the  code  in  the  support  routines  and  any  main-level 
code  that  alters  the  Core-Queue,  Core-Map  or  control 
information,  inhibiting  is  functionally  equivalent  to 
programmed  gating.  Furthermore,  gated  code  can  be 
handled  as  reentrant  code. 


The  courtesy-call,  main-level  interlace  is 
accomplished  by  interlace  controls  (described  later) 
and  by  judiciously  inhibiting  the  allocation  proper 
routines.  Interrupt  breathers  are  strategically 
positioned  within  these  routines  to  allow  the 
interruptions.  At  these  points,  the  main-level 
allocator’s  state  is  known  and  well-defined  by  the 
interlace  controls;  furthermore,  the  interrupt 
breathers  are  chosen  to  be  sufficiently  close. 
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Allocation  Cont/ols 


Allocation  controls  are  classified  by  usage  into 
primary  controls  that  directly  control  allocation 
initiation  or  govern  demand/resource  selection 
criteria,  secondary  controls  that  support  the 
allocation  process,  and  interlace  controls  that 
coordinate  independent  allocation  phases.  Several 
controls  are  necessarily  multi-type. 


Controls 


The  objectives  of  primary  controls  and  their 
associated  logic  ate  to  eliminate  unnecessary 
allocation  passes  and  to  streamline  demand/t esout ce 
selection.  These  objectives  ate  met  via  the 
Core-Queue/Core-Map  Fence  and  the  Static  Dampers. 


Cot  e-Queue/Cor e-Map  Fence 


In  its  simplest  form,  allocation  consists  of  the 
selection  of  a demand  or  resource  followed  by  a serial 
scan  of  available  resources  or  current  demands  in  order 
to  select  one,  subject  to  some  criteria  such  as 
first-fit,  best-fit,  etc.  This  procedure  would  be 
repeated  for  each  demand  or  resource.  During  design  of 
the  allocator  it  was  concluded  that  the  time  by  a 
straight  forward  allocation  method,  as  above,  would 
result  in  an  unacceptable  overhead  burden  on  the 
Executive,  even  with  a small  number  of  demands.  This 
conclusion  was  based  primarily  on  the  expected 
frequency  and  desired  speed  of  the  allocation  process. 


The  Core-Queue/Core-Map  Fence  was  devised  to 
minimize  allocation  and  selection  passes.  The  fence  is 
an  essential  allocation  control  that  functions  as  a 
selection  filter  for  both  demands  and  resources,  along 
with  other  uses  described  later. 
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To  give  meaning  to  the  fence,  the  illustration 
below  depicts  the  sets  of  demands  and  available 
resources  plotced  on  a scale  of  appropriate  resource 
units , 


Available  Resources) (Resource  Demands 

LOW  (Resource  Units  Scale)  High 

Whenever  the  set  of  demands  meets  the  set  of 

avatlables,  allocation  would  be  possible.  However, 
considerable  overhead  can  be  spent  in  determing  when  or 
if  this  condition  exists.  For  example  in  the  simple 
form  of  allocation  given  above,  this  determination  can 
only  be  made  by  examining  each  element  in  one  set 
against  all  the  elements  in  the  other  set.  The  problem 
then  is  to  minimize  the  allocator's  overhead  by 
simplifying  this  feasibility  determination.  This  is 
accomplished  via  the  Cor e-Queue/Cor e-Map  Fence. 


The  Cot e-Queue/Cor e-Map  Fence  is  a logical  barrier 
that  lies  between  the  set  of  availables  and  the  set  of 
demands,  subject  to  the  constraint  that: 

Available  Resources  Resource  Demands 

Low  (Resource  Units  Scale)  High 

where  the  fence  is  located  at  symbol  .FQMIN  in  the 
Communication  Region. 


When  a demand  violates  the  constraint  by  crossing 
over  the  fence  (<) , either  a demand  allocation  attempt 
IS  indicated  or,  if  allocation  is  progress,  the  demand 
IS  selectable  for  further  consideration.  Conversely, 
when  an  available  resource  crosses  over  the  fence  (>), 
resource  allocation  is  indicated  or  this  resource  is 
selectable.  Either  way  the  fence  allows  a ready  check 
of  allocation  feasibility,  though  by  no  means  does  it 
guarantee  its  success. 


The  fence  is  initialized  during  the  Executive's 
initialization  to  the  size  of  assigned,  swapable  cote 
allocated  to  the  Executive.  Dut  ing  execution,  the  fence 
is  adjusted  in  three  possible  ways: 
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1.  Wuen  a demand  ciosses  the  fence  but  cannot  be 
allocated  core,  the  fence  is  set  to  the  demand 
size  minus  one  resource  unit, 

2.  When  an  available  resource  crosses  the  fence, 
the  fence  is  set  to  the  available  resource 
size,  or 

3.  During  main-level  demand  allocation,  the  fence 
is  set  to  the  largest  available  hole  size  if 
there  are  four  or  more  demands  eligible  for 
allocation. 


An  additional  interpretation  that  should  be 
applied  to  the  fence  arises  from  the  above  methods  of 
adjustment.  During  demand  allocation,  the  fence  is 
treated  as  an  upper  bound  on  the  largest  available 
core-hole  and  is  used  as  a demand  selection  filter. 
Notice  that  the  first  adjustment  method  supports  this 
view  because  it  tends  to  refine  the  upper  bound 
property.  Similarly,  resource  allocation  treats  the 
fence  as  a lower  bound  on  the  smallest  demand  in  the 
Core-Queue.  In  this  case  the  lower  bound  property  is 
refined  by  fence  adjustments. 


Because  demand  allocation  is  the  most  prevalent 
type,  main-level  'swap'  resource  allocation  uses  the 
fence  as  a starting  bond  only.  Subsequent  adjustments 
that  would  normally  be  applied  to  the  fence  ate 
actually  applied  to  a true  demand  lower  bound  internal 
to  the  resource  allocation  routine.  This  is  done  to 
preserve  the  available  resource  upper  bound  property 
that  resulted  from  the  demand  allocation  pass. 

In  summary,  the  fence  interpretation  is  biased 
towards  the  upper  resource  bound  property,  with  the 
r elat ion 


< 


always  being  true.  However,  it  is  possible  for  a demand 
to  temporarily  cross  the  fence,  since  it  will  only 
alter  the  fence  after  an  unsuccessful  allocation 


L 


max 

Cor  e-Map 


Ava  liable 
Co t e-Mo le  S i zes 


I 


Cor  e-Queue/Cor  e-Map 
Fence 
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Genet  al 


The  Core  Allocator  can  execute  in  virtually 
asynchronous  allocation  phases  because  it  is  both  event 
driven  and  event  cued.  The  lattei  case  occurs  by  design 
at  the  main-level  in  order  to  centralize  global  calls 
to  the  allocator  and  to  eliminate  untimely  allocation 
passes , 


The  combination  of  cued  and  immediate  allocator 
enables  requires  the  periodic  testing  for  the  presence 
of  a cued  enable  and  the  gating  of  some  allocation 
functions  until  the  enable  is  activated.  The  latter 
requirement  is  necessary  to  protect  the  effect  of  the 
event  on  the  gross  allocation  state. 


The  statis  dampers  were  devised  to  control  and 
interlace  the  external  driven  and  cued  calls  to  the 
allocation  processes  and  to  eliminae  main-level 
allocation  passes,  while  the  gross  demand/resource 
state  remains  static,  by  signaling  when  a 'favorable' 
change  of  state  has  occurred. 


Meaning 


There  are  two  dampers  at  .EDAMP,  each  occupying 
one  cell.  These  are  called  the  Static  Core-Map  Damper 
and  the  Static  Swap  Damper  in  that  order.  The  dampers 
are  two-valued  with  cue  damping  or  'on'  state 
represented  by  a non-zero  value,  which  is  the  IC&I  of 
who  last  turned  the  damper  on. 


The  Static  Cote-Map  Damper  summarizes  the 
relationship  between  the  set  of  demands  and  set  of 
available  (but  not  swapable)  core-holes  by  means  of  the 
Core-Queue/Core-Map  Fence.  When  the  damper  is  on,  core 
assigned  to  the  Executive  is  compact  (packed  tight). 
This  means  no  current  demand  in  the  Core-Queue  up  to 
and  including  the  highest  priority  no-pass  will  fit  in 
any  current  free  core-hole  described  by  the  Core-Map 
given  the  current  hole  distribution.  This  is  the  basic 
interpretation  of  the  damper . When  the  damper  's  state 
IS  tested,  the  question  being  asked  is  whether  or  not 
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core  is  compact,  or  whether  or  not  a logical 
consequence  of  either  compact  allocation  state  is  true. 
The  damper  is  particularly  effective  when  the 
initiation  of  demand  allocation  is  in  doubt.  In  this 
case  an  allocation  attempt  would  be  fruitless  if  the 
damper  is  on  since  free  core  is  compact. 

The  events  associated  with  a possible  change  in 
the  damper's  state  are  the  release  of  core,  the 
linking/unlinking  of  a demand  to/from  the  Core-Queue, 
or  the  completion  of  demand  allocation.  Specifically, 
the  damper  is  turned  off  whenever  a core-hole  crosses 
the  Cote-Queue/Cote-Map  Fence,  a demand  crosses  the 
fence  and  no  attempt  is  made  to  allocate  core  to  it,  or 
the  highest  priority  no-pass  is  unlinked  from  the 
Cote-Queue;  the  damper  is  turned  on  when  main-level 
demand  allocation  complete;  i.e.,  has  serviced  the 
Cote-Queue  up  to  the  highest  priority  no-pass. 

This  damper  is  generally  altered  by  Core-Map 
changes,  so  a static  Core-Map  results  in  a static 
damper  state.  Because  of  this  relationship,  the  damper 
is  called  the  Static  Core-Map  Damper. 


The  Static  Swap  Damper  summarizes  the  relationship 
between  the  set  of  demands  and  the  set  of  'swapable' 
core-holes,  also  by  means  of  the  Core-Queue/Cote-Map 
Fence.  When  this  damper  is  on,  core  assigned  to  the 
Executive  is  compact  up  to  any  'swapable'  holes  and 
their  adjacent  free  core-holes.  This  is  the  basic 
interpretation  of  the  swap  damper.  Even  though  this 
damper's  meaning  and  function  are  similar  to  the  Static 
Core-Map  Damper,  the  swap  damper  is  required  because 
'swapable'  core  resources  are  ri^qt  described  by  the 
Cor  e-Map. 


The  swap  damper's  state  is  affected  by  the  release 
of  core  and  the  1 ink ing/un 1 ink i ny  of  a demand  to/ft om 
the  Core-Queue  similar  to  the  Core-Map  damper.  In 
addition, the  state  can  be  altered  by  designating  an 
assigned  area  of  cote  as  'swapable'  or  by  'swap' 
resource  allocation.  Specifically,  the  damper  is  turned 
o^f f whenever  a 'swapable'  cote-hole  including  adjacent 
free  holes  crosses  the  Core-Queue/Cote-Map  Fence, 
demand  allocation  to  a newly  linked  demand  is  not 
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possible  oi  unsuccessful  and  swap  tesouice  allocation 
IS  not  attempted,  ot  the  highest  priority  no-pass  is 
unlinked  from  the  Core-Queue;  the  damper  is  turned  on 
when  main-level  resource  allocation  is  initiated. 


For  reasons  analogous  to  the  Static  Core-Map 
Damper  's  relationship  to  the  Core-Map,  the  Static  Swap 
Damper  generally  mirrors  any  periods  during  which 
'swapable'  core  resources  remain  static. 

Both  dampers  are  set  on  if  there  are  no  demands 
present,  that  is  the  Core  queue  is  empty,  since  core 
assigned  to  the  Executive  is  considered  to  be  compact 
in  this  case. 


Damper  Usage ; General 


The  static  dampers  are  concerned  with  the  gross 
allocation  problem,  i.e.,  the  sets  of  demands  and 
availables  and  their  relationship.  In  this  context  the 
dampers  ate  used  to  flag  when  allocation  should  be 
initiated  and  to  gate  the  execution  of  selected 
allocation  processes  when  an  external  event  creates  an 
allocation  condition  that  must  be  logically  preserved 
until  the  allocator's  response  is  activated. 

The  main-level  Core  Allocator  is  invoked  when  the 
dampers  ate  off.  Recall  that  an  allocation  pass  through 
the  Cote-Queue  would  be  futile  when  the  dampers  are  on 
since  cote  is  compact  up  to  both  free  and  'swapable' 
holes.  Specific  damper  usage  is  described  in  the 
allocator  phase  overviews  that  follow. 

Notice  that  for  any  specific  allocation  case  (when 
a demand  or  resource  has  been  selected),  the  dampers 
are  meaningful  in  deciding  whether  to  attempt  the 
allocation,  but  they  ate  meaningless  within  the 
allocation  process  itself  because  they  have  no  bearing 
on  demand/  resource  selection. 


The  last  damper  comment  is  a word  of  caution. 
Since  the  dampers  directly  effect  allocator  initiation. 
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the  damper  settings  must  be  carefully  maintained.  If 
they  are  inaccurate  the  core  Allocator  will  suffer  from 
an  excessive  number  of  futile  allocation  passes  or  a 
crippling  lack  of  allocation  passes. 


Main-Level  Allocation 


Main-level  core  allocation  includes  both  demand 
and  swap  resource  allocation  phases.  Demand  selection 
in  both  phases  is  made  from  the  whole  Core-Queue  up  to 
the  highest  priority  no-pass. 


If  both  allocation  methods  are  to  be  initiated, 
demand  allocation  always  precedes  the  resource 
allocation.  This  means  that  free  cote  will  be  filled 
before  any  swap-outs  are  initiated.  Main-level 
allocation  phases  are  so  ordered  because  swapping  is 
considered  to  be  a drastic  allocation  measure. 


Demand  Allocation  Phase 


The  demand  allocation  phase  is  enabled  by  the 
Dispatcher  every  time  it  completes  its  queue  service. 
The  demand  allocator  first  queries  the  Static  Core-Map 
Damper  to  see  if  free  core  is  compact.  If  the  damper  is 
on,  the  demand  allocator  enables  the  swap  resource 
phase  by  passing  the  processor  to  it.  If  the  damper  is 
off,  free  core  is  not  compact;  therefore,  demand 
allocation  is  in  order. 


Prior  to  starting  demand  selection,  a Core-Queue 
selection  depth  tally  is  initialized  to  the  Core-Queue 
depth  of  the  highest  priority  no-pass  if  one  is  present 
or  zero  if  there  is  none.  This  tally  is  used  in  demand 
selection  to  indicate  the  logical  end  of  the 
Cot  e-Queue . 


The  Core-Queue/Core-Map 
demand  selection  filter 
selectable  if  it  crosses  (is 
the  fence  is  being  used 
largest  free  cote  hole.  If  a 


Fence  is  then  used  as  a 
such  that  a demand  is 
<)  the  fence.  Notice  that 
as  an  upper  bound  on  the 
demand  is  selected,  the 
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Core-Map  is  searched  for  the  best-fit  free  core-hole. 
This  search  is  the  resource  selectiorr. 


If  no  fit  is  found,  the  fence  is  adjusted  so  that 
the  selected  demand  does  not  cross  it.  An  interrupt 
breath  is  then  taken  to  allow  courtesy-call 
interruptions  and  demand  selection  is  restored  with  the 
first  demand  following  the  previously  selected  demand. 


If  a best-fit  core-hole  is  found,  the  hole  is 
assigned  to  the  demand  and  the  designated  Keyword 
Processor's  core  load  is  initiated.  During  the  load  the 
size  of  the  demand  is  saved  in  .TPAD  lower  if  its 
associated  TASK  since  the  Core-Map  entry  built  by 
demand/  resource  assignment  occupies  the  same  TASK 
cells  that  the  Core-Queue  entry  describing  the  demand 
used.  The  demand  size  is  used  to  build  the  BAR  after 
the  load  successful!  completes. 


Bypass  counts  of  all  demands  skipped  over  or 
preceding  the  selected  demand  are  then  updated.  If  the 
update  forces  a no-pass,  the  demand  allocation  phase  is 
terminated  and  swap  resource  allocation  is  enabled; 
otherwise,  an  interrupt  breath  is  taken  to  allow 
courtesy-call  interruptions,  followed  by  the  resumption 
of  demand  selection. 


Demand  allocation  terminates  when  either  the 
Core-Queue  selection  depth  tally  runs-out  or  the  end  of 
the  Core-Queue  is  detected.  Prior  to  enabling  the  swap 
resource  phase,  the  Static  Core-Map  Damper  is  set  on. 

This  must  be  done  since  there  are  eligible  demands 
that  will  fit  in  any  of  the  remaining  free  core-holes, 
i.e.,  free  core  is  compact.  Notice  that  the 
Core-Queue/Core-Map  fence  has  been  adjusted  as  a 
resource  upper  bound  during  this  allocation  phase. 

Secondary  Contr o 1 s Associated  with  Demand  Al locat ion 

1 

I 

During  initialization  the  Core  Allocator's  j 

main-level  execution  phase  cell  (.EAIXP)  is  set  to  one. 

This  cell  is  a cour tesy-cal 1/ma in-level  interlace 
control.  The  upper  half  of  the  cell  is  used  by  the 
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coui tesy-cal 1 allocation  tontines  to  maintain  a 
negative  count  of  no-pass's  either  linked  to  the 
Cote-Queue  ot  forced  by  bypass  count  updates  during  the 
interruption  of  the  main-level  demand  allocator.  This 
count  is  effectively  zeroed  at  the  completion  of  the 
main-level  demand  phase.  The  lower  half  of  this  cell 
contains  the  main-level  execution  phase  setting.  This 
is  zero  when  the  main-level  allocator  is  not  enabled, 
one  where  main-level  demand  allocation  is  enabled,  and 
two  when  main-level  'swap'  resource  allocation  is 
enabled . 


Whenever  a demand  is  selected,  the  allocator's 
Cote-Queue  position  and  Cote-Queue  depth  tally  are 
saved  in  cell  .EACQS  for  resumption  of  the  demand 
selection.  The  Core-Queue  position  is  a pointer  to  the 
selected  demand,  in  particular  the  Cote-Queue  entry 
itself.  The  Cote-Queue  selection  depth  tally  has  two 
possible  interpretations.  If  the  tally  is  positive,  it 
represents  the  remaining  number  of  demands  eligible  for 
selection.  This  count  includes  the  highest  priority 
no-pass.  If  the  tally  is  negative,  it  represents  the 
negative  Core-Queue  depth  of  the  selected  demand. 


One  other  cell  set  as  a result  of  a successful 
selection  is  the  main-level  demand  allocator's  current 
Core-Queue  depth  (.ENUQD).  This  is  the  depth  of  the 
selected  demand.  The  depth  is  found  by  subtracting  the 
tally  in  .EACQS  from  the  Cote-Queue  depth  of  the 
highest  priority  no-pass  which  is  kept  in  .ENPQD  lower. 
The  latter  depth  is  zero  if  there  are  no  no-pass's.  The 
allocator's  Core-Queue  depth  is  used  for  courtesy-call 
main-level  interlace. 


Swap  Resource  Al  locat  ion  Ph^e 

The  swap  resource  allocation  phase  is  enabled  by 
the  main-level  demand  allocation  phase.  The  swap 
allocator  first  checks  the  Static  Swap  Damper  to  see  if 
core  is  compact  up  to  swapable  holes.  If  the  damper  is 
on,  core  is  compact,  so  control  is  returned  to  the 
Dispatcher.  Otherwise  the  damper  is  set  mi  and  the  swap 
allocator  chocks  . ESWPE  for  a nonzero  value  to 
determine  if  there  are  any  swapable  core-holes.  If 
there  are  none,  control  is  returned  to  the  Dispatcher, 
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Otherwise,  the  swap  allocator  initializes  itself. 


Prior  to  searching  for  a swapable  hole,  an 
internal  resource  selection  filter  is  set  to  the 
Core-Queue/Cote-Map  Fence  size.  This  filter  is 
maintained  internally  by  the  swap  allocator  as  a lower 
bound  on  the  smallest  demand  so  that  the  fence  will 
remain  the  best  upper  bound  on  the  available  core 
r esources. 


The  Dispatcher ' s-Queue  is  then  searched  for  the 
lowest  priority  Keyword  Processor  that  is  eligible  for 
swap.  This  search  is  the  resource  selection  since  the 
TASK  associated  with  the  swap-eligible  Keyword 
Processor  contains  the  Core-Map  entry  that  describes 
the  swap  hole. 


When  a swap  hole  has  been  found,  the  swap  hole 
size  is  combined  with  the  size  of  any  adjacent  free 
core-holes.  The  total  size  is  then  compared  against  the 
internal  resource  selection  filter  to  see  if  it  is 
potentially  larger  than  the  smallest  demand.  If  the 
size  is  not  greater  than  the  filter,  resource  selection 
is  resumed.  Otherwise  demand  selection  commences  with 
the  total  swap  hole  size  used  as  a selection  filter. 
The  Core-Queue  is  scanned  from  high  to  low  priority. 
All  entries  up  to,  and  including,  the  highest  priority 
no-pass  are  considered  in  the  scan.  The  demand 
selection  criteria  is  'first-fit'. 


If  no  fit  is  found,  the  internal  resource 
selection  filter  is  set  to  the  total  size  of  the 
previously  selected  swap  hole,  an  interrupt  breath  is 
taken  to  allow  courtesy-call  interruptions,  and 
resource  selection  is  restarted. 


If  a fit  is  found,  an  attempt  to  get  a free 
Swap-Map  entry  and  sufficient  swap-file  space  is  made. 
An « unsuccessful  attempt  results  in  an  interrupt  breath 
and  the  resumption  of  resource  selection.  However,  if  a 
map  entry  and  space  are  available,  initial  resource 
assignment  is  made  to  the  selected  demand  by  altering 
the  Core-Map  entry  describing  the  swap  hole  to  include 
the  adjacent  free  core-holes.  The  true  LAL  of  the  swap 
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hole  (that  is  the  LAL  of  the  Keyword  Pi ucessoi 
occupying  tl.^  swap  hole)  is  saved  in  .TPAD  lowei  of  the 
TASK  descrit.ing  the  swap  resource  because  of  the  map 
modification.  In  addition,  a pointer  to  the  replacement 
TASK  is  sav  ! in  .TPAD  upper  of  the  TASK  to  be 
swapped-out . 


Swap-c.  •_  of  the  Keyword  Processor  occupying  the 
swap  hole  i c.  then  initiated  and  the  bypass  counts  of 
those  demands  which  were  skipped  over  are  updated.  Swap 
allocation  terminates  if  this  bypass  count  update 
forces  a ro-pass.  Otherwise  an  interrupt  breath  is 
taken  and  resource  selection  is  restarted  from  the 
previously  selected  resource  in  the  Dispatcher ' s-Queue . 


Swap  resource  allocation  terminates  when  either  a 
no-pass  is  forced  or  the  resource  selection  search 
detects  the  end  of  the  Dispatcher ' s-Queue . In  either 
case,  control  passes  to  the  Dispatcher. 

Secondar  y Contr  ols  Associated  with  Swap  Resour  ce 
Allocation 


There  are  two  secondary  controls  affected  by 
main-level  swap  allocation.  The  first  is  the  Core 
Allocator's  execution  phase  cell  (.EAIXP).  This  cell  is 
set  to  two  at  the  onset  of  swap  resouice  allocation  and 
zero  when  this  allocation  phase  is  completed. 


The  other  cell  affected  is  the  swap  resource 
selection's  dispatcher  ' s-Queue  position  (.ESDQP). 
Whenever  a resource  is  selected,  a pointer  to  the  next 
higher  priority  entry  in  the  Dispatcher ' s-Queue  is 
saved  in  the  upper  half  of  this  cell.  This  pointer  is 
used  for  resumption  of  the  resource  selection's  scan  of 
the  D ispatcher ' s-Queue  and  for  cour tesy-cal 1/ma in-level 
inter  lace . 


Each  time  a swap  resource  is  selected,  demand 
selection  is  started  at  the  beginning  of  the 
Core-Queue.  Interrupt  breaths  are  positioned  after 
demand  selection  (successful  or  not),  but  before 
resumption  of  resource  selection.  Consequently  no 
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Core-Queue  position  controls  are  required  for 
cour tesy-call/main-level  interlace  as  is  the  case  for 
demand  allocation. 


Courtesy-Call  Al location 

Thete  are  two  courtesy-calls  in  which  core 
allocation  can  take  place.  These  are  the  courtesy-calls 
attached  to  the  Transaction  Scheduler's  Intercom  read 
to  TPE  and  the  Keyword  Processor  swap-out  I/O  caused  by 
swap  resource  allocation. 

New  Demand  Allocation 


The  first  courtesy-call  allocation  is  called  'new 
demand'  allocation.  This  is  concerned  with  a new 
tr ansact ion ' s core  demand.  When  the  new  demand  is 
priority  linked  into  the  Core-Queue,  its  allocation 
eligibility  relative  to  the  Core-Queue  is  determined.  A 
demand-not-el ig ible  return  from  the  link  routine 
results  in  the  suspension  of  this  allocation  attempt. 
In  this  case  the  demand  will  have  to  be  serviced  by  the 
main-level  allocator.  If  the  demand  is  eligible  for 
further  allocation  consideration  it  is  called 
' Q-e 1 ig ible ' . In  this  case  an  attempt  to  allocate  core 
to  the  new  demand  must  be  made  because  the  link  routine 
adjusts  the  interlace  controls  under  the  assumption 
that  such  an  attempt  will  be  made. 


Demand  allocation  will  be  attempted  i 
main-level  allocator  was  interrupted  in  its 
phase  or  the  Static  Core-Map  Damper  is  on  and 
new  demand  crosses  the  Cor e-Queue/Coi e-Map 
Allocation  is  permitted  and  necessary 
interruption  of  main-level  demand  allocation 
the  ' Q-e 1 ig ibi 1 1 ty ' of  the  demand  implies  th 
main-level  allocator's  queue  position  is  past 
demand.  If  nothing  is  done  an  indefinite  de 
allocation  to  this  demand  could  result.  Si 
Static  Cote-Map  Damper  will  be  set  on  at  the 
main-level  demand  allocation  phase. 


f the 
demand 
i f the 
Fence . 
dur ing 
because 
at  the 
the  new 
lay  in 
nee  the 
end  of 


A 1 locat ion 


is  permitted  when 


the  damper  is  on 
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because  free  cote  is  compact  and  ' Q-e 1 ig ibi 1 i ty ' in 
this  case  means  the  new  demand's  piiotity  is  greater 
than  that  of  any  no-pass  present  in  the  Core-Queue. 
When  the  damper  is  off  no  allocation  attempt  is  made 
since  this  damper  state  implies  that  a 'favorable' 
Core-Map  change  has  occurred.  This  change  might  be 
sufficient  to  allow  main-level  allocation  to  a demand 
whose  priority  is  greater  than  that  of  the  new  demand. 
Even  though  bypass  logic  would  allow  allocation  to  the 
latter  demand,  it  is  a sense  of  'fair  play'  that 
dictates  the  wait  in  this  case. 


Resource  selection  criteria  is  best  fit.  If  no 
available  resource  fits,  the  fence  is  adjusted  so  that 
the  new  demand  no  longer  crosses  it.  Otherwise  having 
successfully  selected  a resource,  core  assignment  is 
made,  the  transaction  designated  Keyword  Processor's 
core-load  is  initiated  and  the  bypass  counts  of 
higher -pr ior ity  demands  in  the  Core-Queue  are  updated. 
If  a no-pass  is  forced  by  the  update,  the  upper  half  of 
the  main-level  allocator  's  execution  phase  cell 
(.EAIXP)  is  decremented  by  one.  Control  is  then 
returned  to  the  Transaction  Scheduler. 


If  demand  allocation  was  not  allowed  or  not 
successful,  swap  allocation  is  considered.  The 
main-level  allocator's  execution  phase  cell  (.EAIXP)  is 
queried  to  check  if  a no-pass  was  forced  or  linked 
within  a cour tesv-call . If  a negative  no-pass  count 
exists,  the  main-level  allocator's  phase  checks  are 
bypassed.  Otherwise  the  main-level's  phase  is  examined 
as  follows. 


If  the  main-level  was  interrupted  in  its  demand 
phase,  the  Static  Swap  Damper  is  turned  off  to  force  a 
main-level  swap  allocation  attempt.  I'his  is  done 
because  swap  allocation  within  the  courtesy-call  could 
freeze-up  free  core-holes,  making  them  inaccessible  to 
the  ma i n- leve 1 . 


If  the  main-level  was  interrupted  in  the  swap 
phase,  the  position  of  its  'swap'  resource  selection 
within  the  Dispatcher  's-Queuo  ( . ESDQP)  is  reset  to  the 
start  of  the  queue.  This  is  done  so  all  swap  holes  will 
be  re-examined  in  light  of  the  new  demand. 
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In  either  case  of  main-level  allocator 
interruption,  control  is  returned  to  the  Transaction 
Scheduler . 


At  this  time  the  Static  Swap  Damper  is  checked  to 
determine  if  swapable  core  is  compact.  If  it  the  damper 
is  off,  indicating  that  it  is  not  compact,  allocation 
IS  suspended  and  control  returned  to  the  scheduler. 
Otherwise  swap  resource  selection  is  initiated  for  the 
new  demand.  Resource  selection  criteria  is  first-fit. 
If  a resource  is  found,  swap-out  of  the  Keyword 
Processor  occupying  the  swap-hole  is  initiated  and 
bypass  counts  are  updated.  If  a no-pass  is  forced,  the 
courtesy-call  no-pass  count  in  .EAIXP  upper  is 
decremented  by  one. 


Whether  or  not  the  swap  allocation  is  successful, 
control  is  returned  to  the  Transaction  Scheduler. 


Swap-Out  Allocation 

Swap-out  courtesy-call  allocation  is  concerned 
with  the  free  core  hole  created  by  a Keyword  Processor 
swap-out  as  a result  of  swap  resource  allocation.  This 
core-hole  requires  special  handling  because  it  can  be 
the  sum  of  non-contiguous  free  core-holes  plus  part  of 
the  intervening  swap-hole. 

The  major  complication  occurs  when  the  Keyword 
Processor's  swap-out  courtesy-call  interrupts  the 
main-level  in  its  demand  phase.  If  the  free  hole 
created  by  the  swap-out  is  larger  than  any  existing 
hole.  It  is  conceivable  that  a demand  already  rejected 
by  main-level  demand  selection  could  fit  within  this 
hole.  If  nothing  is  done,  the  passed  over  demand  could 
lose-out  to  a lower  priority  demand  yet  to  be  examined 
by  main-level  demand  selection.  Even  though  bypass 
logic  would  permit  this  to  happen,  it  definitely  is  not 
the  purpose  or  intent  of  such  logic,  particularly  since 
the  higher  priority  demand  might  fit  in  the  new  hole. 

This  problem  can  be  rectified  in  two  ways.  The 
main-level  demand  allocator's  Core-Queue  position  could 
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be  repositioned  via  the  interlace  control.  .EACQS  to 
the  start  of  the  queue.  This  would  result  in  all 
demands  being  reconsidered  in  light  of  the  new 
core-hole.  The  selected  method  is  to  try  to  allocate 
the  new  hole  to  those  demands  already  rejected  or 
passed  over  by  the  main-level.  This  method  was  chosen 
for  timing  reasons  only. 

During  the  swap-out  courtesy-call,  the  LAL  of  the 
swap  partition  is  adjusted  to  the  upper  address  limit 
(UAL)  of  the  previous  (lower  address)  core  partition. 
This  is  equivalent  to  combining  the  swap  partition  with 
the  free  hole  below  it.  True  core  assignment  to  the 
demand  to  be  swapped-in  can  then  be  rade.  At  this  time 
the  free  hole  resulting  from  the  swup-out  is  known  and 
described  by  the  Core-Map  entry  built  for  the  demand 
being  loaded.  The  size  of  the  hole  is  compared  to  the 
Cor e-Queue/Cor e-Map  Fence  to  see  if  it  is  the  largest 
free  core-hole.  If  the  hole  size  does  not  cross  the 
fence  (>),  this  indicates  that  it  is  not  the  largest 
and  that  core  allocation  need  not  be  attempted. 
Otherwise,  the  Core-Queue  is  checked  to  see  if  any 
demands  are  present.  If  it  is  empty  the  fence  is  set  to 
the  size  of  the  free  hole  and  of  course  no  allocation 
is  attempted. 

If  there  are  demands,  resource  allocation  will  be 
attempted.  In  this  case,  the  main-level  allocator's 
execution  phase  must  be  queried.  If  the  main-level  was 
interrupted  in  its  demand  allocation  phase,  a demand 
selection  tally  is  set  to  the  Core-Queue  depth  of  the 
main-level  allocator's  demand  selection.  This  tally  is 
used  so  only  those  demands  already  rejected  by  the 
main-level  will  be  considered.  If  the  main-level  was 
interrupted  in  its  swap  resource  phase  or  not 
interrupted  at  all,  the  demand  selection  tally  is  set 
to  the  Cote-Queue  depth  of  the  highest  priority  no-pass 
or  zero  if  none.  In  this  case  all  eligible  demands  will 
be  consider  ed . 


Recalling  that  the  objective  is  to  allocate  the 
swap  created  hole,  demand  selection  commences. 
Selection  criteria  is  first-fit.  If  a fit  is  found, 
resource  assignment  is  made,  cote-load  of  the  demand 
associated  Keyword  Processor  is  initiated,  and  bypass 
counts  are  ufidated.  If  a no-pass  is  forced,  the  count 
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of  courtesy-call  no-pass’s 
incremented.  Notice  that 
demand  resource  assignment 
describes  any  residue  of 
excess  of  this  demand. 


in  .EAIXP  is  negatively 
the  Core-Map  entry  built  by 
for  the  selected  demand 
the  free  hole  that  was  in 


Resource  allocation  continues  until  the  demand 
selection  tally  tuns  out  or  the  free  core-hole  residue 
no  longer  crosses  the  Core-Queue/Cot e-Map  Fence.  In  the 
former  case,  the  hole  residue  is  compared  to  the  fence 
since  it  could  still  cross  it.  If  the  cote  residue  does 
cross  the  fence,  then  the  fence  is  set  to  the  size  of 
the  residue  hole. 


When  resource  allocation  has  terminated  or  if  no 
allocation  was  attempted,  a check  is  made  to  see  if  the 
remaining  free  core-hole  lies  below  (lower  address)  a 
swap  hole.  If  it  does  the  total  size  of  the  swap  hole 
is  computed  and  compared  to  the  fence.  If  the  total 
hole  size  crosses  the  fence  and  the  main-level 
allocator  was  not  inter  r upted  or  inter  r upted  iri  the 
demand  phase , the  Static  Swap  Damper  Ts  turned  off. 
This  will  trigger  the  main-level  swap  resource  phase, 
which  will  try  to  allocate  the  swap-hole.  If  the 
main-level's  phase  is  neither  of  the  above,  it  must  be 
in  its  swap  resource  allocation  phase.  In  this  case, 
the  main-level's  resource  selection  position  within  the 
Dispatcher ' s-Queue  (.ESDQP)  is  reset  to  the  beginning 
of  the  queue  so  that  all  swap  holes  will  be  re-selected 
and  examined.  A straightfor ward  check  of  whether  the 
main-level  is  past  the  swap  hole  in  question  is  not 
possible.  This  is  because  the  Dispatcher ' s-Queue  is  not 
linked  serially  and  no  queue  depths  ate  maintained  for 
its  entries.  Consequently  any  repositioning  must  be  to 
the  start  of  the  queue. 


At  this  time  the  swap  created  hole  has  been 
incorporated  into  the  gross  allocation  state.  All  that 
remains  is  to  process  the  swapped-out  Keyword 
Processor's  demand.  The  associated  TASK  is  linked  to 
the  Dispatcher  's-Queue  at  this  time.  If  the  TASK  is 
marked  for  abort  or  if  it  is  GEWAKE’d,  it  is  left 
linked  to  the  queue  and  the  courtesy-call  is 
terminated.  Otherwise  it  is  unlinked  and  subsequently 
linked  to  the  Cote-Queue. 
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If  the  link  routine  specifies  that  the  demand  is 
' Q-e 1 ig ible ' , an  allocation  attempt  must  be  made.  This 
IS  accomplished  by  calling  the  'new  demand'  allocation 
much  like  the  Transaction  Scheduler  does.  Upon  return 
the  courtesy-call  is  ended. 


The  swapped-out  demand  is  purposely  linked  to  the 
Core-Queue  cf ter  the  swap  created  hole  has  been 
allocated.  This  order  is  followed  because  a Keyword 
Processor  is  generally  marked  eligible  for  swap  as  a 
result  of  excessive  resource  usage. 
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Cor  e Allocator  Entr  y Points 


Symbol 

Title 

CALOlO 

Link  New  TASK  to  Core-Queue 

CALOll 

Link  Old  TASK  to  Core-Queue 

CAL060 

Unlink  TASK  from  Core-Queue 

CAL090 

Main-Level  Core  Allocator 

CAL120 

New  TASK  Allocator 

CAL140 

Allocate  Core  Start  Load 

CAL150 

Allocate  Core  Start  Swap 

CAL160 

Update  Bypass  Counts 

CAL164 

Get  No-pass  Q-depth 

CAL170 

Initialize  Swap-Eligible  TASK  Search 

CAL171 

Resume  Swap-Eligible  TASK  Search 

CAL180 

Load/Swap-in  Courtesy-Call 

CAL190 

Swap-out  Courtesy-Call 

CAL220 

Release  Core  & Adjust  Allocator' 

s Controls 

CAL230 

Calculate  & Check  Size  of  'Swap' 

Hole 

CAL240 

Mark  TASK  Eligible  for  Swap 

CAL250 

Check  Swap/Load  I/O  Status 

AIOIOO 

Setup  & Do  Swap-in  I/O 

AIOIIO 

Setup  & Do  Swap-out/Swap-in  I/O 

AI0120 

Setup  & Do  Startup  Rollout 
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Link  to  Cot  e-Queue 


FUNCTION; 


This  routine  links  a TASK  via  cells  .TMEM  and 
.TPRIO  to  the  Core-Queue  according  to  the  priority 
assigned  to  the  TASK  in  .TPRIO.  Affected  Cote 
Allocator  controls  ate  updated.  The  routine  also 
determines  the  allocation  elibigility  of  the  newly 
linked  TASK  relative  to  any  no-pass  present  in  the 
Core-Queue  and  to  the  main-level  Cote  Allocator, 
if  it  was  interrupted  within  its  Demand  Phase. 


ENTRIES 


Common  calling  parameter  is: 

CPI  - L(TASK)  to  be  linked  to  the  Core-Queue. 

EPl  - Link  New  TASK  to  Core-Queue  (CALOlO). 

This  entry  calls  an  optional  routine  to 
assign  an  initial  priority  and  bypass  count 
in  .TPRIO  and  .TLAL  respectively. 

EP2  - Link  Old  TASK  to  Core-Queue  (CALOll). 

This  entry  uses  existing  values  in  .TPRIO  and 
.TLAL. 

RETURNS : 

RRl  - Call+1,  Not  eligible  for  allocation. 

RR2  - Call+2  Eligible  for  allocation. 
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unlink  Cote-Q  Entr 
FUNCTION: 


This  routine  unlinks  cells  .TMEM  and  .TPRIO  of  the 
designated  TASK  from  the  Core-Queue.  Core 
Allocator  controls  are  updated. 

ENTRIES: 

EP  1 - Unlink  Core-Queue  Entry  (CAL060) . 

CPI  - L(TASK)  to  be  unlinked  from  Core-Queue. 

RETURNS: 

Return  is  made  to  the  calling  routine  at  Call+1. 
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Main-Level  Core  Allocation 


FUNCTION: 


This  routine  attempts  to  allocate  core  from 
existing  free  core-holes  (demand  allocation) 
if  the  Static  Core-Map  Damper  (.EDAMP)  is 
off.  The  routine  also  attempts  to  allocate 
core  from  holes  that  would  be  created  by 
swapping-out  swap-eligible  Keyword  Processors 
(swap  resource  allocation),  if  the  Static 
Swap  Damper  (.EDAMP+1)  is  off.  In  both  cases 
the  Core-Queue  is  serviced  up  through  the 
highest  priority  no-pass,  if  any,  or  the  end 
of  the  queue. 


ENTRIES: 


EPl  - Main-Level  Core  Allocator  (CAL090) . 


This  entry  is  called  exclusively  by  the 
Dispatcher  after  its  queue  service. 


RETURNS: 


Return  is  always  to  the  Dispatcher. 
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New  TASK  Allocation 


FUNCTION: 


This  routine  attempts  to  allocate  core  to  a 
new  TASK  received  by  the  Transaction 
Scheduler  or  spawned  via  a Keyword 
Processor-to-Keyword  Processor  communication 
request.  This  routine  assumes  that  all 
Core-Queue  eligibility  criteria  have  been  met 
by  the  designated  TASK.  Both  demand  and  swap 
are  conditionally  attempted.  This  routine 
generally  executes  at  the  courtesy-call 
level . 


ENTRIES : 

EPl  - New  TASK  Allocation  (CAL120) . 

CPI  - L(TASK)  to  allocate  core  to. 

RETURNS: 

Return  is  made  to  the  Call+1. 
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Allocate  Core  Start  Load 
FUNCTION : 


This  routine  unlinks  the  designated  TASK  from 
the  Core-Queue  and  allocates  core  to  the  TASK 
by  building  a Coi e-Map  entry  in  .TMEM  and 
.TLAL.  Core  is  normally  allocated  at  the  top 
of  the  specified  hole  except  when  the  hole  is 
above  (higher  cote  address)  a swap-eligible 
TASK.  In  the  latter  case,  core  is  allocated 
at  the  bottom  of  the  hole.  Lastly,  the 
routine  starts  the  necessary  load/swap-in 
I/O. 


ENTRIES: 


EPl  - Allocate  Core  Start  Load  (CAL140) . 

CPI  - L(TASK)  to  which  core  is  to  be 
allocated  to. 

CP2  - L(Core-Map  entry)  which  holds  the 
core-hole  to  be  allocated. 


RETURNS: 


Return  is  made  to  the  Call+1. 
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d 


Allocate  Core  Start  Swap 


f FUNCTION; 

I 

This  routine  attempts  to  get  Swap-File  space 
and  a free  Swap-Map  entry  in  which  to  reserve 
the  space  for  the  designated  swap-eligible 
TASK.  If  successful,  the  free  core-hole  lying 
above  the  swap-eligible  Keyword  Processor  is 
combined  with  the  core  partition  described  by 
the  swap-eligible  TASK'S  Core-Map  entry  and 
the  sv/ap-out  of  the  swap-eligible  Keyword 
Processor  is  initiated. 


ENTRIES: 


EPl  - Allocate  Core  Start  Swap  (CAL150)  . 
CPI  - L(TASK)  to  be  swapped-out. 
CP2  - L(TASK)  to  be  swapped-in. 


RETURNS: 


RRl  - Call+1,  Insufficient  swap-file  space  to 
start  swap . 

RR2  - Call+2,  Swap-out  started. 
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Update  Bypass  Counts 
FUNCTION: 


This  routine  dectements  the  bypass  count  of 
each  TASK  in  the  Coi e-Queue  starting  with  the 
TASK  pointed  to  by  .TRAD  upper  of  the 
designated  TASK  and  continuing  to  the  start 
of  the  Core-Queue.  No-pass  TASKS  (TASKS  whose 
bypass  counts  have  junout)  that  are  forced  by 
the  update  are  linked  via  the  upper  half  of 
their  respective  .TRAD  cells  in  high  to  low 
priority  sequence.  The  base  of  the  no-pass 
chain  is  recorded  in  .ENRQD.  Lastly,  the 
Core-Queue  depth  of  the  highest  priority 
no-pass  is  calculated  and  saved  in  .ENRQD 
lower  . 


ENTRIES: 

ERl  - Update  Bypass  Counts  (CAL160). 

CRl  - L(TASK)  holding  backwards  Core-Q 
pointer  for  update. 

ER2  - Get  No-pass  Q-Depth  (CAL164) . 

No  calling  parameters. 

RETURNS: 

RRl  - Cal  1 + 1,  No-pass  present  in  .ENRQD. 

RR2  - Call+2,  Bypass. 

For  ERl,  a new  higher  priority  no-pass  was  not 
forced  by  this  bypass  count  update,  but 
an  old  no-pass  might  be  in  effect. 

For  ER2,  no  no-pass  is  in  effect. 
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Swap-Eligible  TASK  Seat  ch 


FUNCTION: 


This  routine  searches  the  Dispatcher ' s-Queue 
for  a TASK  that  is  flagged  as  eligible  to  be 
swapped  in  its  .TFLAG  cell.  This  condition  is 
indicatd  if  the  B.TESW  bit  flag  is  on.  If  a 
TASK  is  found,  the  number  of  free  core  blocks 
(1024  words),  which  would  be  freed  up  if  the 
TASK  were  swapped-out,  is  calculated.* 


ENTRIES: 


EPl 


Initialize 
(CAL170) . 


Swap-El igible 


Search 


This  entry  initializes  the  search 
relative  to  the  current  disposition  of 
the  Dispatcher ' s-Queue. 

No  calling  parameters. 


EP2  - Continue  Swap-Eligible  Search  (CAL171). 

This  entry  resumes  the  search  using  the 
last  position  saved  in  Communication 
Region  cell  .ESDQP. 


No 

ca 

* The 

number 

of 

the 

cu 

r r ent 
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pr 
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calling  parameters. 


freed-up  core  blocks  is  the  sum 
■ partition  size  and  the  size 


of 

of 
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RETURNS: 

RRl 


! 


I 


I 

i 


Call+l,  No  swap-eligible  TASKS. 
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Swap-Eligible  TASK  Search 
RETURNS: 

RR2  - Call+2,  Swap-eligible  TASK  found. 

RPl  - L (Swap-eligible  TASK). 

RP2  - Number  of  core  blocks  that  would  be 
freed-up  by  a swap. 
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Load/Swap-in  Courtesy-Call 


FUNCTION: 


This  routine  initializes  a new  or  previously 
swapped  Keyword  Processor  after  it  has  been 
loaded  into  core.  If  necessary,  swap-file 
space  is  released.  The  BAR  and  other  controls 
are  constructed  if  the  load  was  successful 
and  the  TASK  is  linked  to  the 
Dispatcher 's-Queue. 


ENTRIES: 


This  routine  is  Courtesy-Call  driven. 


RETURNS: 

Return  is  made  to  GCOS  via  a MME  GEENDC. 


Iri.  18 


r 


1 


CORE  ALLOCATOR 


Swap-out  Cour  tesy-Call 


FUNCTION; 


This  routine  deallocates  cote  from  the 
swapped-out  TASK,  combines  the  fteed-up  core 
with  any  adjacent  available  core  and 
allocates  the  total  to  the  TASK  to  be 
swapped-in.  Swap-in  is  then  initiated  and 
the  swapped-out  TASK  is  unlinked  from  the 
Dispatcher ' s-Queue  and  linked  to  the 
Cote-Queue,  if  it  is  not  marked  for  abort. 
Lastly,  an  attempt  is  made  to  allocate  the 
core-hole  resulting  from  the  swap.  If  the 
main-level  Core  Allocator  was  interrupted 
during  its  demand  (load)  allocation  phase, 
only  those  TASKs  already  serviced  by  the 
main-level  allocator  are  considered. 


ENTRIES: 


This  routine  is  Courtesy-Call  driven. 


RETURNS: 


Return  is  made  to  GCOS  via  a MME  GEENDC. 
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Release  Cot  e & Adjust  Aliocatoi  ' s Contt  ols 


FUNCTION: 


This  routine  releases  all  core  assigned  to  the 
designated  TASK.  It  is  subsequently  adjusts  the 
Cote  Allocatot's  Core-Queue/Core-Map  fence 
(.EQMIN)  and  Static  dampers  (.EDAMP)  as  required. 


ENTRIES : 


EPl 


Release  Core  & Adjust 
(CAL220) . 


CPI  - L(TASK)  from 
released . 


Allocator ' s 


which  core 


Controls 


is  to  be 


RETURNS  : 


Return  is  always  passed  to  the  Call+1. 
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Calculate  & Check  Size  of  ' Swap ' Hole 
FUNCTION: 


This  routine  calculates  the  number  of  contiguous 
core  blocks  that  would  be  freed-up  if  the 
designated  TASK  were  swapped-out.  (Core-holes 
above  and  below  the  designated  TASK  are  combined 
with  the  core  space  assigned  to  the  TASK  to  get 
the  resulting  hole  size).  The  size  of  the  'Swap' 
hole  is  then  compared  to  .EQMIN,  the 
Cot e-Queue/Cof e-Map  Fence. 


ENTRIES: 


EPl  - Calculate  & Check  Size  of  'Swap'  Hole 
(CAL230) . 


CPI  - L(Swap-eligible  TASK). 


RETURNS: 


RRl  - Cal+1,  'Swap'  hole  size  <=. EQMIN. 


RR2  - Call+2,  'Swap'  hole  size  > .EQMIN. 
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Mark  TASK  Eligible  for  Swap 


FUNCTION: 


This  routine  is  intended  as  a one-stop  call  to 
flag  a TASK  as  eligible  for  swap  and  to  adjust 
any  affected  Core  Allocator  controls.  Convenience 
aside,  this  routine  exists  to  minimize  code  that 
adjusts  the  Core  Allocator's  Dampers. 

Caution:  Once  a TASK  is  marked  eligible  for  swap, 
inhibited  code  must  be  used  to  prevent  the  swap 
from  possibly  happening  at  the  courtesy-call 
level.  Therefore,  either  (1)  all  processing  that 
requires  the  TASK  to  be  in-core  should  be  done 
before  calling  this  routine  or  (2)  inhibited  code 
should  be  employed  during  such  processing  after 
return  from  this  routine. 


ENTRIES: 


EPl  - Mark  TASK  Eligible  for  Swap  (CAL240). 

CPI  - Pointer  to  TASK  eligible  for  swap. 


RETURNS: 


Return  is  always  made  to  call+1. 

RPl  - Size  of  the  'swap'  hole  that  would  be 
created  by  swapping-out  the  designated  TASK. 


la. 42 


L J 


CORE  ALLOCATOR 


Check  Swip/Load  J/0  Status 


FUNCTION: 


This  routine  checks  the  major  status  code  for  all 
Keyword  Processor  swap/load  I/O.  If  the  status  is 
bad,  the  affected  TASK  is  flagged  for  abort  and 
the  appropriate  error  code  is  inserted  into  the 
TASK. 


ENTRIES: 


EPl  - Check  Swap/Load  I/O  Status  (CAL250)  . 

CPI  - Code  to  identify  the  calling  routine 
(currently  either  the  Load/Swap-in 
Courtesy-Call  or  the  Swap-out 
Courtesy-Call) . 

CP2  - L(TASK) . 

CP3  - Core-LAL  of  the  associated  Keyword 
Processor . 


RETURNS: 


Return  is  always  to  the  Call+1. 


18.43 


CORE  ALLOCATOR 


Check  Swap/Load  I/O  Status 


FUNCTION: 


This  routine  checks  the  major  status  code  for  all 
Keyword  Processor  swap/load  I/O.  If  the  status  is 
bad,  the  affected  TASK  is  flagged  for  abort  and 
the  appropriate  error  code  is  inserted  into  the 
TASK. 


ENTRIES : 


EPl  - Check  Swap/Load  I/O  Status  (CAL250) . 

CPI  - Code  to  identify  the  calling  routine 
(currently  either  the  Load/Swap-in 
Courtesy-Call  or  the  Swap-out 

Courtesy-Call) . 

CP2  - L(TASK) . 

CP3  - Core  LAL  of  the  associated  Keyword 
Pr  ocessor . 


RETURNS: 


Return  is  always  to  the  Call+1. 


M. 
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Do  Core  Allocator  I/O  ^ 

FUNCTION  i 


This  routine  performs  disc  I/O  for  the  Core 
Allocator  by  building  the  I/O  Select-  Sequence 
and  necessary  DCWs,  depending  on  the  entry 
point.  A pointer  to  the  appropriate 
courtesy-call  routine  is  inserted  into  the 
Courtesy-Call  Vector  (.TCCV)  in  the  TASK. 


ENTRIES: 


EPl  - Swap-In  (AIOIOO) . 

CPI  - L(TASK)  to  be  swapped-in. 


EP2  - Swap-Out/Swap-in  (AIOllO)  . 

CPI  - L(TASK)  to  be  swapped-out. 

CP2  - L(TASK)  to  be  swapped-in. 

EP3  - Startup  Roll-Out  (AIO120) . 

CPI  - L(Pseudo  TASK)  used  by 

Initialization  Routine. 


RETURNS: 


Return  is  always  to  the  Call+1. 
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Function 


The  Dispatcher  functions  primarily  to  select 
eligible  TASKS  for  dispatch  on  a priority  basis;  to 
monitor  the  status  of  system  functions,  gross  Executive 
resource  utilization  and  TASK  system  requests;  and  to 
enable  system  functions  and  services. 


Introduction 


The  Dispatcher  is  the  control  focal  point  of  the 
Executive  because  control  is  always  passed  or  returned 
to  it.  As  a result  it  is  responsible  for  monitoring  all 
other  internal  Executive  functions  and  for  periodically 
or  reflexly  enabling  them.  Through  its  queue  all  TASKs 
eligible  for  dispatch  or  requiring  a system  service  are 
known . 


The  normal  sequence  of  events  within  the 
Dispatcher  is  to  service  its  queue;  conditionally 
enable  system  functions;  and  select,  then  dispatch  to 
an  eligible  Keyword  Processor. 


Dispatcher  ' s Queue 


All  TASKS  eligible  for  dispatch  or  requiring  an 
Executive  service  are  linked  together  to  form  the 
Dispatcher ' s-Queue . A queue-entry  proper  consists  of 
TASK  cells  .TPRIO,  .TFLAG  and  .TFLAG+1.  The  queue  is 
forward  and  backward  linked  with  pointers  to  the  head 
and  tail  of  the  queue  along  with  the  number  of  TASKs 
linked  to  the  queue  maintained  in  Communication  Cell 
. EDSPQ. 


The  TASKS  are  chained  together  according  to  the 
priorities  assigned  in  the  lower  half  of  their  .TPRIO 
cells.  When  following  the  forward  queue  pointers  in  the 
upper  half  of  the  queue-entry  (.TPRIO  cells),  the 
priority  sequence  is  ascending,  and  when  following  the 
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backward  queue  pointers  in  the  upper  half  of  the 
queue-entry  (.TFLAG  cells)  the  priority  sequence  is 
descending . 


Queue  entry  cells  .TFLAG  lower  and  .TFLAG+l  lower 
contain  attribute  and  status  bit  flags.  Attribute  flags 
define  the  characteristics  of  the  Keyword  Processor 
designated  by  TASK  cell  .TSID.  These  flags  are  copied 
from  the  Keyword  Processor  Profile  when  the  transaction 
is  first  received  by  the  Executive.  Status  flags  define 
the  current  processing  state  of  the  Keyword  Processor 
and  which  queues  the  TASK  is  linked  to. 


The  bit  flags  in  .TFLAG  lower  are  further  labeled 
'Q-scanned'  flags.  This  label  serves  to  differentiate 
between  those  flags  used  by  the  Dispatcher ' s-Queue 
Service  and  Dispatch  Select,  and  those  that  aren't. 
This  grouping  of  the  bit  flags  is  a consequence  of  the 
method  used  to  scan  the  queue. 


Specifically,  the  .TPRIO  cell  of  all  TASKS  is 
assembled  with  an  even  offset  from  the  origin  of  the 
TASK.  Furthermore  the  space  assigned  for  TASK 
construction  in  the  Executive  has  zero  origin  mod  2.  As 
a result,  TASK  cells  .TPRIO  and  .TFLAG  form  an  even 
word  pair  since  .TFLAG  always  follows  .TPRIO.  This  is 
done  to  allow  logical  operations  on  the  bit  flags  in 
.TFLAG  lower  to  be  executed  with  a minimum  of 
instructions  when  following  either  the  forward  or 
backward  Dispatcher  ' s-Queue  pointers. 


Bit  flags  that  are  to  be  used  to  'single-out'  a 
TASK  when  examining  the  queue  as  a whole  are  placed  in 
.TFLAG  lower.  Since  these  flags  are  used  when  the  queue 
is  processed  or  searched,  they  are  called  'Q-scanned'. 
Pit  flags  that  are  queried  relative  to  a known  TASK  or 
queue-entry  are  placed  in  .TFLAG+l. 

Notice  that  TASK  cell  .TPRIO  is  ued  both  in  a 
Dispatcher ' s-Queue  entry  and  a Core-Queue  entry. 
Consequently,  a TASK  cannot  be  linked  to  both  queues 
simultaneously . 
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Some  Executive  services  and  functions,  which  are 
directly  identifiable  with  a specific  TASK,  cannot  be 
initiated  when  their  need  is  indicated  or  cannot 
complete  their  function  when  given  control.  For 
example,  TASK  termination  cannot  be  initiated  within 
courtesy-call  and  requests  for  buffer  space  might  be 
unsuccessful.  When  these  service  conditions  occur,  it 
is  necessary  to  queue  the  request  in  order  that  the 
function  can  be  either  initiated  or  restarted, 
whichever  the  case. 


A queue  is  not  defined  for  each  such  service  since 
the  necessary  queue-entry  information  would  be 
essentially  the  same;  thus  independent  of  the 
particular  service.  A generic  queue-entry  would  contain 
a pointer  to  the  TASK  that  was  being  processed  and  the 
IC&I  where  the  service  is  to  be  given  control. 


Only  one  queue  is  required  and  this  queue  is 
embedded  as  an  integral  part  of  the  Dispatcher ' s-Queue . 
Relative  to  this  queue,  the  only  queue-entry  parameter 
is  the  service  IC&I  in  which  the  queue-entry  lies  and 
thereby  identifies  the  TASK  being  processed  by  the 
service. 


The  Dispatcher ' s-Queue  Service  detects  and  enables 
the  TASK  associated  service  requests  as  dictated  by  its 
queue . 
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Dispatcher  ' s Dynamic  Queue  Service  Mask 

The  service  mask  is  used  to  select  those  queue 
entries  within  the  Dispatcher ' s-Queue  that  are  waiting 
to  be  serviced.  The  mask  is  positioned  at  symbolic 
location  .EDQSM  within  the  Communication  Region. 


The  service  mask  is  the  logical  sum  (OR)  of  those 
'Q-scanned'  bits  which  flag  a service  request.  Notice 
that  this  can  be  formed  as  a binary  sum  since  the 
applicable  bit  flag  definitions  (B.XXXX)  do  not 
overlap. 

During  the  Dispatcher ' s-Queue  Service,  the  mask  is 
serially  'ANDed"  to  the  "Q-scanned'  bits  in  .TFLAG 
lower  of  each  queue-entry.  If  the  product  is  non  zero, 
one  or  more  of  the  'Q-scanned*  bits  being  queried  by 
the  mask  has  been  set  on  (is  one).  This  means  the 
queue-entry  under  examination  is  waiting  for  a service. 

The  service  bit  mask  can  be  dynamically  altered  to 
allow  the  conditional  selection  of  some  services.  The 
idea  here  is  to  let  the  mask  reflect  an  internal 
'go/nogo'  service  status  so  that  when  a service  cannot 
be  provided,  the  waiting  queue  entries  are  not  detected 
(ignored)  in  the  queue  scan. 

Not  all  services  can  be  summarized  so  succiently. 
However,  it  is  the  nature  of  some  services  that  allows 
the  determination  of  whether  future  requests  can  be 
satisfied.  These  services  effectively  disable 
themselves  when  they  can  no  longer  accomplish  their 
function.  In  these  cases,  there  is  a complementary 
system  function  for  each  service  that  determines  when 
the  service  can  be  enabled. 


An  example  of  such  a service  is  the  processing  of 
Intercom-Queue  entries.  When  an  available  entry  is 
requested  and  there  is  only  one  remaining,  it  is  clear 
that  once  this  entry  is  assigned,  future  queue  requests 
would  be  fruitless.  Whenever  this  occurs,  the  service 
would  suspend  itself.  When  a queue-entry  is  released  by 
the  complementary  service  and  it  is  the  only 
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queue-entry  available,  queue  requests  would  again  be 
enabled . 


All  services  that  can  be  dynamically 
enabled/disabled  via  the  service  mask  must  be  assigned 
dedicated  'Q-scanned'  bit  flags.  The  remaining  services 
that  are  not  so  conditioned  could  be  lumped  together 
into  one  bit  flag.  This  is  seldom  done,  however,  since 
the  'Q-scanned'  bits  also  serve  to  describe  the  state 
of  the  Keyword  Processor  represented  by  the 
queue-entry . 


Recognition  of  a particular  service's  request  is 
disabled  by  'ANDing'  the  Dispatcher ' s-Queue  Service 
Mask  with  the  1 ' s-complement  of  the  services 's  related 
'Q-scanned'  bit  flag.  That  is  setting  the  appropriate 
bit  off  in  the  mask.  Recognition  is  enabled  by  simply 
'ORing'  the  'Q-scanned'  bit  flag  back  on  in  the  service 
mask . 


Queue  Service : When  and  How 


The  Dispatcher ' s-Queue  Service  is  enabled  whenever 
a Keyword  Processor  timer  runout  occurs  or  an  initial 
system  service  or  function  request  cannot  complete  or 
does  not  return  to  the  Keyword  Processor.  When 
initiated,  the  lower  half  of  the  Dispatcher  ' s-Queue 
Service  Position  cell  (.EDQSP)  in  the  Communication 
Region  is  set  to  a non-zero  value.  This  halfword  is 
used  to  indicate  that  the  queue  service  has  been 
activated  and  is  in  progress. 


At  this  time  the  TASK  Alarm  Clock  (.ETACK)  is 
checked  to  set  if  it  has  been  set,  that  is  not  -1.  If 
so  the  time  of  day  is  obtained  and  saved  in 
Communication  Region  cell  .ETIME.  If  the  TASK  Alarm 
Clock  is  ringing  (.ETACK  < .ETIME),  the 
Dispatcher ' s-Queue  Service  Mask  is  adjusted  so  that 
GWAKE'd  TASKS  linked  to  the  Dispatcher ' s-Queue  will  be 
detected.  Actual  scan  of  the  queue  is  then 
initiated,  starting  with  the  highest  priority  entry  or 
TASK  linked  to  it.  The  scan  is  continued  via  the 
backward  queue  pointers  in  the  upper  half  of  the 
queue-entry  .TEhAG  cells.  The  queue  service  mask  is 
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used,  as  explained  earlier,  to  recognize  those  entries 
awaiting  service. 


When  an  entry  is  found,  a pointer  to  the  next 
queue-entry  is  saved  in  cell  .EDQSP  upper  for  later 
resumption  of  the  scan.  This  cell  is  also  necessary  to 
protect  the  queue  service  from  getting  'lost',  since 
the  Dispatcher  or  the  service  routine  it  enables  might 
be  interrupted  by  a courtesy-call  that  links  or  unlinks 
an  entry  to  the  Dispatcher ' s-Queue.  In  this  context 
.EDQSP  functions  as  a main-level/courtesy-call 
interlace  control. 


The  queue  service  is  terminated  when  the  scan 
detects  a zero  backward  Dispatcher ' s-Queue  pointer,  or 
resumption  of  the  queue  service  finds  .EDQSP  upper  is 
zero.  The  latter  case  occurs  if  the  lowest  priority 
queue-entry  was  last  recognized  for  service  so  that  the 
next  backward  queue-entry  pointer,  saved  in  .EDQSP, 
would  be  zero. 


Service  Initiation/Restart 


The  D i spatcher ' s-Queue  does  not  attempt  t'-' 
determine  what  ■ eeded  by  t ouIuclou  queue 
entrj  ....om  uie  "t;-scanned'  bits  set  on  in  the  entry. 
The  basic  reason  for  this  design  appr o;:;ch  is  Lwofo.a: 
(1)  t’'.i  service  or  function  is  the  logical  place 
wherein  internal  and  service  related  TASK  status  should 
be  examined  and  the  necessary  processing  course  plotted 
when  the  functions  cannot  be  initiated  or  completed, 
since  all  necessary  information  is  known  at  that  point; 
and  (2)  the  Dispatcher's  design  remains  open-ended  with 
this  modular  service  approach.  As  a result  the 
Dispatcher  is  not  burdened  with  having  to  arrange  and 
classify  the  different  bit  flag  combinations  that  may 
be  present  in  the  queue-entry. 


A service  vector  in  .TFLAG+1 
used  to  enable  the  processing  for 
vector  is  the  IC  of  where  the 
control.  When  the  Dispatcher  has 
waiting  for  service,  it  saves 
associated  TASK  and  checks  the 


upper  of  the  entry  is 
a selected  entry.  The 
service  is  to  be  given 
detected  a queue-entry 
the  pointer  to  the 
service  vector  to  make 
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sure  i*-.  is  not  zero.  If  zero,  the  TASK  is  aborted; 
otherwise  the  IC  is  saved  and  the  service  vector  is 
zeroed.  At  this  time  the  service  is  enabled. 


Only  the  TASK  pointer  is  currently  supplied  for 
the  service,  no  other  cells  set  by  a dispatch  are 
supported . 


Service  Considerations  and  Restrictions 


When  a service  is  unable  to  complete  its  function, 
it  is  the  service ' s responsibility  to: 


(1)  Ensure  that  the  associated  TASK  is  linked 
the  Dispatcher ' s-Queue, 


to 


(2)  Set  the  appropriate  'Q-scanned'  bit  flag  on 
in  the  TASK  so  the  service  can  be  restarted, 
and 


(3) 


Set  the 
to  the 
control 
enabled 


service  vector  in  .TFLAG+1  to  point 
location  where  the  service  wishes 
to  be  returned  when  it  is  later 
to  attempt  to  complete  its  function. 


There  are  two  resti ictions  that  must  be  observed 
by  the  service  functions  when  it  is  necessary  to  use 
the  Dispatcher ' s-Queue  Service.  Only  one  level  of  IC 
depth  is  allowed  the  service  when  it  disables  itself. 
This  means  that  if  control  is  one  or  more  levels 
removed  from  the  service  routine  proper  when  the 
determination  of  service  dysfunction  is  made,  control 
must  be  returned  up  to  a point  where  one  IC  defines  the 
service's  position,  i.e.,  to  where  the  service  becomes 
reusable.  This  problem  is  currently  unavoidable  with  in 
the  Executive's  modular  structure  since  there  is  no 
service  IC  stack  within  the  TASK. 


The  other  restriction  applies  to  data  storage  for 
the  service  routine  when  it  cannot  complete.  The  only 
storage  area  allowed  the  service  is  the  TASK  space  from 
.TPAD+1  through  the  end  of  the  TASK.  The  size  of  this 
area  is  variable  depending  on  the  values  supplied  the 
.TASK  macro  during  the  Executive's  assembly.  All  TASK 
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I 

or  Keyword  Processor  related  data  must  be  saved  in  this 
area,  however  it  is  intended  that  the  amount  of  data  be 
a minimum.  If  a service  is  frequently  requested  and  its 
dysfunction  judqed  to  be  likely,  consideration  should 
be  given  to  defining  additional  TASK  cells  to  hold  the 
necessary  information. 


When  the 
Dispatcher ' s-Queue 
responsibility  to 
was  used  to  flag  a 
designated  TASK, 
subsequent  attempt 
original  request, 
would  be  zero  from 
would  be  aborted. 


service  is  enabled  by  the 
Service,  it  is  the  service ' s 
turn  off  the  "Q-scanned'  bit  which 
'need  service'  state  within  the 
Failure  to  do  so  could  result  in  a 
by  the  queue  service  to  process  the 
In  this  case,  the  service  vector 
the  original  enable  so  the  TASK 


Service  Returns 


Service  routines  that  cannot  complete  their 
function  or  do  not  return  control  to  a Keyword 
Processor  must  return  to  the  Dispatcher  at  symbolic 
location  ncnim  whan  *-his  occurs,  the 
Dispatcher ' s-Queue  Service  is  either  initiated  oi 
resumed . 


Service  routines  that  can  be  initiated  or 
restarted  by  the  queue  service  and  that  successfully 
complete  their  function  must  return  to  DSP302  i^  they 
return  contiol  to  a Keyword  Processor.  When  such  a 
return  occuis,  the  D ispatcher ' s-Queue  Service  Position 
(.EDQSP)  is  checked  to  see  if  the  queue  service  is 
enabled.  If  so,  the  service  is  restarted  where  it  left 
off,  otherwise  a GELBAR  is  reissued  to  the  Keyword 
Processor  that  was  serviced.  Thus  a GEhBAR  or  dispatch 
IS  pevjL?  issued  to  a successfully  serviced  Keyword 
Processor  when  the  service  was  enabled  by  the 
Dispatcher  ' s-Queue  Service. 


System  Funcjtion  Enables 


When  the  Dispatcher  has  coinpleted  its  queue 
service,  it  enable  the  Transaction  ScheiUilei  , Cote 
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Allocator  and  Remote  I/O  Supervisor 


The  Transaction  Scheduler  is  enabled  both  to  issue 
the  first  Intercom  read  to  TPE  at  startup  time  and  to 
restart  the  scheduler  in  the  event  it  has  stalled-out. 
Recall  that  once  the  scheduler  is  enabled,  it  continues 
to  request  transactions  from  TPE  at  the  courtesy-call 
level  until  it  cannot  obtain  a free  TASK  or  sufficient 
input  buffer  space,  both  being  required  for  each  read 
that  it  issues.  When  this  occurs  the  Scheduler  is  said 
to  have  stalled-out  since  it  must  terminate  its 
courtesy-call  without  issuing  an  I/O. 


Normally  the  Transaction  Scheduler  ignores  the 
enable  by  simply  returning  control  to  the  Dispatcher. 
However,  if  the  scheduler  has  stalled-out  as  indicated 
by  communicat ions  cell  .ESTAL,  the  enable  causes  the 
scheduler  to  try  to  restart  itself. 


The  Core  Allocator  treats  the  Dispatcher's  enable 
in  much  the  same  fashion.  That  is,  the  enable  may 
result  in  an  allocation  attempt  or  it  may  be  ignored. 
Decisions  in  this  case  are  based  on  the  static  dampers 
at  Communication  Region  cell  .EDAMP. 


The  Remote  I/O  Supervisor  uses  its  enable  to 
perform  line  service  functions  whici  cannot  be  event 
driven  or  initiated.  This  includes  new  connect 
processing  and  'sleep'/time  disconnecting  processing. 


Pis patch -Select 


The  function  of  Dispatch-Select  is  to  select  that 
highest  priority  TASK  linked  to  the  Dispatcher ' s-Cueue 
whose  Keyword  Processor  can  make  immediate  use  of  the 
processor.  A Keyword  Processor  can  gain  control  only  by 
selected . 


In  general,  dispatching  select  logic  is  a two 
phase  process.  The  phases  are  the  priority  selection  of 
a TA.SK  followed  by  a determination  of  processor 
eligibility  for  the  chosen  TASK.  The  select  procediue 
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consists  of  first  selecting  a TASK  from  the 
Dispatcher ' s-Queue  according  to  a priority  algorithum. 
Having  chosen  a priority-eligible  TASK,  a test  is  then 
made  to  see  if  the  TASK  related  Keyword  Processor  can 
make  immediate  use  of  the  processor.  If  so,  a dispatch 
can  be  paid  to  the  Keyword  Processor;  otherwise  the 
select  procedure  must  be  repeated,  this  time  selecting 
the  next  highest  priority  TASK  linked  to  the  oueue. 


Within  the  Executive,  Dispatch-Select  priority 
logic  is  priority  pre-emptive.  This  choice  results  in 
the  priority  selection  being  implicitly  accomplished  by 
processing  the  Dispatcher ' s-Queue  from  high  to  low 
priority,  i.e.,  by  following  the  backward  queue 
pointers.  Thus  whenever  Dispatch-Select  is  initiated, 
priority  TASK  selection  always  starts  with  the  highest 
priority  TASK  linked  to  the  queue,  even  if  it  was  the 
last  TASK  that  was  dispatched  to. 


Once  a TASK  has  been  priority  selected,  its 
processor  eligibility  is  determined  with  the 
Dispatcher's  Se lect-t I ig ibi I i ty  Nask.  This  mask 
functions  identically  to  the  Dispatcher ' s-Queue  Service 
Mask.  The  mask  is  applied  to  the  'Q-scanned'  bits  in 
.TELAG  of  the  selectei)  queue-entry.  This  is  the  second 
use  of  the  "Q-scanned"  bits.  In  this  context  the 
applicable  bit  ilags  are  used  to  indicate  those  Keyword 
Processor  i;onditions  which  make  it  ineligible  for 
Droce:;.sor  assiunment  . 


Actual  p i spatch-'^r  1 ect  is  accomplished  by  scanning 
the  P isna t che r ' s-Oueue  from  high  to  low  priority  using 
the  Dispatcher's  Se  lect -i' I ig  i b i 1 i t y Vask.  Within  this 
scan,  a ououe-entry  is  selectable  for  dispatch  if  the 
lociical  product  of  the  mask  and  the  entry's  'Q-scanned' 
bits  is  zero. 


Dispatch 


A Keyword  Processor  oispatcii  can  result  t r om  a 
Dispatch  Select,  an  I/O  inter ruit  that  breaks  a 
uispaLch  or  the  successlul  completion  ot  an  initial 
fault  service  request. 
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Dispatch  to  a Keyword  Processor  is  effected  by  a 
MME  GELBAR.  As  such,  a dispatch  consists  of: 

(1)  Adjusting  the  BAR  to  the  Keyword  Processor's 
memory  bounds, 

(2)  Loading  the  timer  register  with  the  dispatch 
time  quantum, 

(3)  Restoring  the  processor  registers  and  EIS 
address  registers,  pointer  and  length 
registers  as  last  set  by  the  Keyword 
Processor,  and 

(4)  Transferring  control  to  the  Keyword  Processor 
at  its  last  interrupted  location. 


All  information  required  by  the  GELBAR  is 
maintained  in  TASK  cells  .TBAR,  .TICI  and  .TTIMO  except 
for  the  processor  register  values  which  are  safe-stored 
at  symbolic  location  .KRFG  in  the  Keyword  Processor's 
Prefix  and  in  TASK  areas  .TAREG  and  .TEPL,  Notice  that 
a pointer  to  .KRFG  is  maintained  in  the  lower  half  of 
.TPAR. 


The  GELBAR  time  quantum  is  set  to  a literal 
constant  of  64  ms  within  the  Dispatcher  except  when 
cell  .TTIMQ  of  the  selected  TASK  is  not  zero.  In  the 
latter  case  the  time  quantum  is  set  to  the  time 
remaining  from  an  earlier  dispatch  as  saved  in  .TTIMO. 


Dispatching  with  variable  time  quantums  of  less 
than  04ms  (for  uniprocessor  system)  is  currently  not 
effective  and  not  done  within  the  Executive.  The  reason 
is  that  .MFALT  does  not  differentiate  between  a GELBAR 
tim,cr  runout  (THO)  and  a normal  TKO.  In  either  case, 
the  Executive  will  be  taken  out  of  execution  and  the 
processor  reassigned.  Consequently,  any  time  remaining 
from  the  GCOS  dispatch  to  the  Executive  is  lost. 


Executive  commun ica t ion  cells  .FBAS5,  .FI. DSP, 
.FTTVO  and  , p’TPEG  are  set  at  each  dispatch.  These  cells 
identify  the  Keyword  Processor  disnatched  to  and 
facilitate  fault  and  interrupt  handling. 


19.11 


DISPATCHER 


Lockup  Log ic 

The  purpose  of  Lockup  Logic  is  to  monitor  the 
Executives  gross  state,  when  it  is  unable  to  find 
anything  to  do  even  though  the  Dispatcher ' s-Queue  is 
not  empty,  and  to  prevent  it  from  slipping  into  a 
comatose  state  of  successive  rel inouishes.  Lockups  are 
classified  as  temporary,  resource  and  unknown. 

A temporary  lockup  is  one  that  normal  processing 
will  remove,  thus  it  is  considered  an  acceptable 
Executive  state.  As  an  example,  such  a lockup  could  be 
caused  by  one  TASK,  linked  to  the  Dispatcher's  Queue, 
that  is  waiting  for  the  completion  of  device  I/O.  This 
type  of  lockup  always  results  in  the  Executive 
relinquishing  control. 


A resource  lockup  represents  a deadly  embrace 
among  two  or  more  Keyword  Processor  over  some  Executive 
allocated  resource.  This  type  of  lockup  will  not  be 
removed  by  normal  processing.  Currently  resource  lockup 
can  occur  because  (1)  available  output  buffer  space  is 
exhausted  and  output  Intercom  is  not  executing  to  flush 
the  buffer,  thus  deadlocking  those  Keyword  Processors 
requesting  additional  buffer  space;  or  (2)  TASK  space 
is  exhausted  thus  deadlocking  the  Transaction  Scheduler 
and  those  Keyword  Processors  reouesting  spawn  TASKS. 
Resource  lockup  can  possibly  be  removed  by  serially 
aborting  those  i:eyword  Processors  in  the  embrace. 


Pnknown  lockup  is  a catch  all.  That  is,  if  the 
Executive  is  dead  and  it  can  not  be  determined  why,  the 
lockup  is  unknown.  In  this  event,  the  Executive  is 
unnraclouslv  aborted  by  the  Dispatcher. 


Prior  to  attempting  to  identify  the  nature  of  the 
lockup,  the  accumulated  status  of  all  TASKS  linked  to 
the  D ispatcher  ' G-Queue  is  formed  L'y  'Ol.ing'  together 
their  "Q-scanned';  bit  flags.  The  logical  sum  is  then 
used  for  lockup  thresholu  tests. 

If  the  lockur;  IS  teiiiporary  the  i;xecutive 
re  I inqu  i.shes  control.  Otherwise  it  i.;  assumeu  that  a 
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lockup  threshold  exists  and  the  resource  lockup  flag 
(.ERLUF)  is  examined  for  a nonzero  value.  The  flag  is 
used  to  indicate,  by  a nonzero  value,  that  there  has 
been  two  consecutive  unsuccessful  Dispatch-Select 
attempts  and  consequently,  two  consecutive  enables  of 
lockup  logic.  If  the  flag  is  zero,  it  is  set  on  and 
control  is  passed  to  the  Dispatcher ' s-Queue  Service  for 
a one-pass  attempt  to  unlock  the  threshold.  If  it  is 
successful  and  the  subsequent  Dispatch  Select  finds  an 
eligible  TASK,  the  resource  lockup  flag  is  turned  off. 


If  the  flag  is  non-zero, 
the  threshold  type  is  made 
status.  If  the  threshold  is 
priority  TASK  in  the  deadly 
the  TASK  termination  is  comple 
to  the  Dispatcher ' s-Queue  se 
pass  will  determine  if  suffici 
to  make  a Dispatch  Select 
logic  will  again  be  enabled  a 
TASK  of  those  remaining  will 
of  events  could  continue  unti 
aborted  in  which  case  the 
ineffectively  removed. 


an  attempt  to  determine 
from  the  accumulated  TASK 
identified,  thw  lowest 
embrace  is  aborted.  When 
te,  control  is  returned 
rvice.  This  queue  service 
ent  resoure  was  freed-up 
possible.  If  not,  lockup 
nd  the  lowest  priority 
be  aborted.  This  sequence 
I all  TASKS  have  been 
threshold  would  have  been 


If  a known  threshold  cannot  be  determined  or  does 
not  exist,  the  lockup  is  unknown  and  the  Executive  is 
aborted  by  the  Dispatcher. 
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Dispatcher  Entry  Points 


Symbol 

Title 

DSPlOl 

Dispatch  After 

GELBAR  Timer  Run-Out 

DSP102 

Service 

Dispatcher ' s-Queue 

DSP301 

Startup 

DSP302 

Reissue 

GELBAR 

After  Service 

DSP303 

Reissue 

GELRAR 

After  Fault 

DSP304 

Reissue 

GELBAR 

After  Fault  (With  Time  Quantum) 

DSP305 

Reissue 

GELBAR 

After  I/O  Interrupt 

DSP600 

Link  TASK  to  Dispatcher ' s-Queue 

DSP800 

Unlink  TASK  From  D ispatcher ' s-Queue 

DISPATCHER 


Dispatcher  Entry  Points 


The  Dispatcher  allows  nine  entry  points,  none  of 
which  return  control  to  the  original  routine  that 
transferred  control  to  it. 


ENTRIES: 


EPl  - Startup  (DSP301). 

Control  is  transferred  to  this  entry  point  at 
the  completion  of  initialization. 


EP2  - Dispatch  after  GELBAR  TRO  (DSPlOl) . 

Control  is  transferred  to  this  entry  point 
whenever  a timer  runout  occurs  within  a 
GELBAR.  TASK  and  Dispatcher ' s-Queue 

accounting  are  performed  via  this  entry 
point . 

CPI  - PTR  to  faulting  TASK. 


EP3  - Service  Dispatcher ' s-Cueue  (DSP102) . 

Control  is  transferred  to  this  entry  point  by 
abor t/terminat ion  routines  and  by  Keyword 
Processor  service  routines  that  cannot 
complete  the  requested  service.  This  entry 
either  initiates  or  resumes  the 
Dispatcher ' s-Queue  Service  depending  on 
. EDQSP. 


EP4  - Reissue  GELBAR  after  Service  (DSP3U2)  . 

Control  is  transferred  to  this  entry  point  by 
Keyword  Processor  service  routines  that 
complete  the  requested  service.  It  the 
service  was  enabled  by  the  Dispatcher ' s-Queue 
Servcice,  control  is  routed  to  resume  the 
queue  service;  otherwise,  a GELBAR  is 
reissued  to  the  serviced  Keyword  Processor, 
This  entry  should  only  be  used  by  services 

19,15 


DISPATCHER 


that  can  be  initiated  or  restarted  by  the 
Dispatcher ' s-Queue  Service. 

CPI  - Pointer  to  serviced  TASK. 


EPS  - Reissue  GELBAR  after  Fault  (DSP303) . 

Control  is  transferred  to  this  entry  point  by 
services  that  cannot  be  initiated  or 
restarted  by  the  D ispatcher ' s-Queue  Service. 
This  entry  reissues  the  GELBAR  after  a 
Keyword  Processor  fault  or  service  reouest 
has  been  successfully  serviced. 

CPI  - Pointer  to  TASK. 


EP6  - Reissue  GFLBAP  after  Fault  (DSP304) . 

This  entry  is  identical  to  EPS,  except  the 
GFLBAR  time  quantum  must  be  specified  for 
this  entry  point. 

CPI  - Pointer  to  TASK. 

CP2  - GELBAR  time  quantum. 


EPb  - Reissue  GELBAR  after  I/O  Interrupt  (DSP3U5) . 

Control  is  transferred  to  this  entry  point  by 
the  Fault  Handler  whenever  a GELBAR  is  broken 
by  an  I/O  interrupt.  The  Dispatcher  reissues 
the  GELBAR  with  the  time  set  to  the  time 
remaining  from  the  original  dispatch. 

CPl  - Pointer  to  TASK. 

CP2  - Time  cuantum  remaininq  from  last 
GFr.RAR. 
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Link  TASK  to  Dispatcher 's-Queue 
FUNCTION: 

This  routine  links  a TASK  into  the 
Dispatcher ' s-Oueue  using  the  TASK  priority  present 
in  TASK  cell  .TPRIO  lower. 

ENTRIES: 

EPl  - Link  Task  to  Dispatcher ' s-Queue  (DSP600) . 
CPI  - Pointer  to  TASK  to  link. 

RETURNS: 


Return  is  always  to  Call+1. 
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Pi-SJgatcher  ' s-yuuue 


FUNCTION; 

This  routine  unlinks  a TASK  from  the 
Dispatcher ' s-Queue  and  updates  TASK  Status  Flags 
and  Dispatcher ' s-Oueue  controls. 


ENTRIES : 

FPl  - Unlink  TASK  from  Dispatcher ' s-Queue 
(DRP800) . 

CPI  - Pointer  to  TASK  to  unlink. 


RETURNS: 


Return  is  always  to  Call+1. 
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FUNCTION: 


This  routine  searches  the  Dispatcher ' s-Queue  for 
the  hiqhest  priority  TASK  that  is  eligible  to  be 
dispatched  to.  Eligibility  is  determined  by 
checking  the  status  flags  in  TASK  cell  .TFLAG 
lower.  Currently,  a TASK  is  selectable  if  the 
following  status  flags  are  off: 

- Device  I/O 

- Swapping-Out 

- In  abort 

- In  Term 

- Need  Abort 

- Need  Output  Buffer  Space 

- Need  Output  Intercom-Queue  Entry 

- Need  Spawn  TASK 

- Need  Wake-Up 

FMTRIFS : 


FPl  - Select  TASK  for  Dispatch  (DSPSFL) . 
No  Calling  parameters. 


RETURNS : 


HHl  - Call+1,  No  eligible  TASKS. 

RR2  - Call+2,  Eligible  TASK  found. 

RPl  - Pointer  to  cell  .Tflag  of  the  selected  TASK. 
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TASK  Terminator  Function 


The  TASK  terminator  functions  to  release  allocated 
resources  back  to  the  Executive,  reassign  a reusable 
Keyword  Processor,  queue  Executive  messages  to  the -user 
or  TPE  and  to  complete  wrapup  measurements. 


The  terminator  is  called  for  both  normal  and 
abnormal  TASK  terminations  and  always  returns  control 
to  the  Dispatcher.  It  is  written  to  execute  at  the 
main-level  only. 


Abnormal  Termination 


Abnormal  termination  can  be  called  not  only  to 
abort  an  in-core  Keyword  Processor,  ' Jt  also  to  abort  a 
TASK  whose  Keyword  Processor  has  been  swapped-out  or 
possibly  never  loaded  into  core. 


Assigned  buffer  resources  are  first  released  by 
removing  the  input  transaction  from  the  Input  Buffer, 
if  present  or  removing  all  output  message  segments  from 
the  Output  Buffer,  if  any.  TASK  cell  .TMSG2  is  checked 
to  see  if  it  has  any  queue  entries  linked  to  the  Output 
Intercom  Queue.  If  so,  the  queue  is  searched  to  find 
those  entries  which  specify  the  abort  TASK  as  the 
originating  TASK.  Each  such  queue-entry  is  unlinked 
from  the  queue  and  the  Output  Buffer  space  assigned  to 
the  queue-entty-def ined  message  segments  is  released. 


TASK  cell  .TSPWN  is  examined  to  determine  if  the 
TASK  belongs  to  a spawn  TASK  chain.  If  it  does,  all 
other  TASKS  linked  to  the  chain  are  flagged  for  abort 
and  linked  to  the  Dispatcher ' s-Queue , if  necessary. 
Notice  that  TASKs  Linked  to  a spawn  chain  cannot  be 
identified  by  a unique  transaction  number,  i.e.,  all 
chained  TASKS  specify  the  same  transaction  number  so 
that  this  number  only  identifies  the  chain  as  a whole 
and  not  the  individual  TASKS.  As  a result,  spawn  chain 
processina  dictates  that  the  spawn  chain  itself  must  be 
aborted  if  a chain  member  aborts. 
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Abnormal  termination  processing  is  complete  at 
this  point  anti  the  remaining  termination  is 
accomplished  by  the  normal  termination  phase.  However, 
all  device  I/O  or  Keyword  Processor  load/swap-out  I/O 
must  be  allowed  to  complete  before  the  normal 
termination  can  be  initiated.  If  any  I/O  is 
outstandinu,  the  TASK  is  linked  to  the 
n isoat  ciie r ' s-Oueue  and  the  TASK  Service  Vector  is  set 
for  normal  termination  so  that  the  processinq  can  be 
completed  later. 


Normal  Termination 


Normal  Termination  assumes  the  terminating  TASK'S 
Keyword  Processor  is  in-core,  unless  the  TASK  was 
received  from  abnormal  terininat  ion.  For  a 'true'  normal 
termination,  a check  is  first  made  to  see  if  the 
Keyword  Processor  is  'reusable'.  This  means  that  the 
Keyword  Processor  can  be  assigned  to  a new  TASK  for 
subsequent  processing  of  tne  latter's  transaction. 


If  it  is,  the  terminating  TASK'S  Keyword  Processor 
Profile  is  located  ana  examined  to  see  if  there  are  any 
new  TASKS  awaiting  core  allocation;  i.e.,  linked  to  the 
Core-  Queue.  If  there  are  none,  the  TASK  is  treated  as 
if  its  Keyword  Processor  was  not  reusable.  Otherwise, 
the  Core-Queue  is  searched  from  high  to  low  [priority  to 
find  those  TASKS  which  identify  the  same  profile  as  the 
terminating  m/ypps.  when  one  is  found,  its  status  flags 
are  checked  to  see  if  it  is  a new  TASK.  If  it  is  an  old 
TASK  it  is  discarded,  otherwise  its  allocation 
elioibilitv  relative  to  the  highest  priority  no-pass 
(see  Core  Allocator  discussion)  is  determined.  A TASK 
which  is  fiot  eligible,  stops  the  search  and  the 
terminating  TASK  is  again  treated  as  not  reusable. 
However,  an  eligible  TASK  results  in  the  assignment  of 
the  terminating  TASKs  Keyword  Processor  to  the  new 
TASK.  Affected  Core  Allocator  controls  are  ui)dated 
since  this  assignment  represents  core  allocation  to  the 
new  TASK. 


If  the  terminating  TASK  is  not  reusable,  checks 
are  made  to  see  if  it  is  linked  to  the  Core-Queue  or 
its  Keyword  Processor  is  in-core  or  swapped-out.  The 
TASK  is  conditionally  unlinked  from  tfie  queue  or  its 
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assigned  core/swap-file  space  is  released. 


! A check  is  then  applied  to  all  terminating  TASKS 

I to  determine  if  they  belong  to  a spawn  TASK  chain.  If 

i not,  an  Executive  message  is  queued  for  Intercom  output 

I to  TPE  and  possible  the  user.  This  message  can  be  an 

I error  message  or  just  an  output  message  header 

1 specifying  an  End-of-Transaction  status  for  the 

' transaction  number  assigned  to  the  terminating  TASK 

(see  Intercom  I/O  Handler  discussion). 

I 

Lastly,  the  TASK  is  unlinked  from  the 
Dispatcher ' s-Queue  and  the  TASK  space  is  released. 


i 

1 
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Symbol  Title 

TRMIOO  Start  TASK  abort 

TPM370  Restart  TASK  Abort 

TRM400  Start  TASK  Termination 

TRM720  Restart  TASK  Termination 

(Need  Output  Buffer  Space) 

TRM74L)  Restart  TASK  Termination 

(Need  Output  Intercom-Queue  Entry) 

FXMluU  Executive  Message  Intercom 

ETXlUO  Convert  t<  I'd.rt  Transaction  Number 
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Terminator  Entry  Points 


The  Terminator  handles  both  normal  and  abnormal 
TASK  terminations.  The  Terminator  allows  five 
entry  points  all  of  which  ultimely  transfer 
control  to  the  Dispatcher *s-Queue  Service. 


ENTRIES : 


Common  calling  parameters  for  all  entry  points  ate: 


CPl  - L(TASK)  to  be  aborted  or  terminated. 


EPl  - Start  TASK  abort  (TRMlOO). 


Control  is  transferred  to  this  entry  point 
when  the  designated  TASK  is  to  be  aborted. 

Cell  .TERRM  in  the  TASK  must  hold  the  error 
code . 


EP2  - Restart  TASK  Abort  (TRM370) . 


Control  is  transferred  to  this  entry  point  by 
the  Dispatcher ' s-Queue  Service  when  a 
previous  attempt  to  abort  a TASK  could  not  be 
completed . 


EP3  - Start  TASK  Termination  {TKH400)  . 


Control  is  transferred  to  this  entry  point 
when  a Keyword  Processor  has  successfully 
completed  its  processing  of  a transaction. 
Core  and  swap-file  space  are  released  if  the 
Keyword  Processor  is  not  reusable  or  there 
are  no  outstanding  messages  requiring  the 
Keyword  Processor.  A EOT  message  is  sent  to 
TPE  and  the  TASK  is  unlinked  from  the 
necessary  aueues  with  optional  accounting. 
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EP4  - Restart  TASK  Termination  - Need  Output  Buffer 
Space  (TRM720) . 


Control  is  transferred  to  this  entry  point  by 
the  Dispatcher ' s-Queue  Service  when  prior 
attempts  to  terminate  a TASK  were  roadblocked 
by  insufficient  Output  Buffer  space. 


EPS  - Restart  TASK  Termination  - Need  Output 
Intercom-Queue  Entry  (TRM740) . 


Control  is  transferred  to  this  entry  point  by 
the  Dispatcher ' s-Queue  Service  when  prior 
attempts  to  terminate  a TASK  were  roadblocked 
by  lack  of  an  Output  Intercom-Queue  Entry. 


RETURNS: 

Return  is  always  to  the  Dispatcher ' s-Queue  Service 
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Initiate  Output  Intercom 


The  Executive's  Output  Intercom  Processor  is 
responsible  for  controlling  and  sending  all  Intercom 
output  that  is  to  be  written  to  TPE.  The  output 
processor  is  functionally  interfaced  to  the  Executive 
by  means  of  the  Output  Intercom-Queue.  Its  component 
routines  issue  the  'true'  Intercom  output  requests 
necessary  to  transfer  the  waiting  messages  to  TPE. 


Introduction 


The  Output  Intercom  Processor  executes  at  the 
courtesy-call  level  once  it  has  been  enabled.  It 
remains  enabled  at  this  level  as  long  as  there  is  an 
output  message  request  waiting  in  the  Output 
Intercom-Queue.  When  the  queue  has  been  emptied,  the 
output  processor  disables  itself.  This  mode  of 
operation  results  in  the  asynchronous  execution  of  the 
Output  Intercom  Processor  and  the  remainder  of  the 
Executive. 


Output  Message  Request 


when  an  Intercom  output  message  is  ready  to  be 
written,  it  must  be  passed  to  the  Output  intercom 
Processor  via  the  Output  Intercom-Queue.  This  is  done 
by  first  requesting  an  available  oueue-entry. 
Unassigned  queue  entries  are  managed  by  communication 
cell  .ECOMQ. 


In  the  event  that  there  are  no  free  entries,  the 
request  must  be  periodically  repeated  until  satisfied. 
The  Dispatcher ' s-Queue  service  is  the  normal  means  used 
to  enable  or  restart  a request.  This  procedure  allows 
any  other  Executive  processing  to  be  acted  on  in  the 
interim. 


Once  a free  queue-entry  can  be  assigned  to  the 
message,  the  entry  is  filled-in  with  message  specifics. 
In  particular,  the  queue-entry  holds  a pointer  to  the 
first  segment  of  the  message,  the  priority  assigned  to 
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the  message  and  the  location  of  the  originating  TASK, 
if  one.  All  control  information  regarding  this  message 
IS  deleted  from  the  originating  TASK  after  a 
queue-entry  is  built  for  it. 


The  output  request  is  effectively  communicated  to 
the  Output  Intercom  Processor  by  linking  the  previously 
built  queue-entry  to  the  Output  Intercom-Queue.  The 
queue  entries  are  linked  according  to  their  assigned 
priorities  with  pointers  to  the  first  and  last  linked 
entries  maintained  in  Communication  Region  cell  .ECQP. 
If  the  output  message  has  an  originating  TASK,  the 
number  of  assigned  and  linked  queue  entries  is 
incremented  in  cell  .TMSG2  of  the  applicable  TASK. 


Enabling  the  Output  Intercom  Processor 


The  Output  Intercom  Processor  must  be  explicitly 
enabled  at  the  main-level  to  initiate  output 
processing.  The  output  processor  must  be  enabled 
whenever  a new  entry  is  linked  to  the  Output 
Intercom-Queue.  If  the  enable  does  not  immediately 
follow  the  call  to  the  link  routine,  the  intervening 
code  must  be  inhibited. 


The  output  processor  always  returns  control  when 
enabled  at  the  main-level.  The  main-level  enable  is 
ignoreo  if  tiie  outpui  i^.rucessor  is  already  executing  at 
the  courtesy-call  level.  The  output-processor 
oetermines  its  courtesy-call  state  by  testing 
communication  cell  .ECONO,  when  this  cell  is  non-zero, 
the  output  processor  is  enabled  at  the  courtesy-call 
level,  so  that  all  currently  linked  queue  entries  will 
be  processed. 
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Overview 


Once  enabled,  the  output  processor  retrieves  and 
unlinks  the  highest  priority  Output  Intercom-Queue 
entry  using  communication  cell  .ECQP.  If  the 
queue-entry  has  an  associated  TASK,  the  count  of  linked 
queue  entries  within  the  TASK  is  decremented.  The 
contents  of  the  queue-entry  are  copied  and  the 
queue-entry  space  is  released  via  the  .ECOMQ  cells. 


Starting  with  the  first  message  segment,  the 
output  processor  issues  an  Intercom  output  request  to 
transfer  the  segment  to  TPE.  The  DCW  word  count  for  the 
segment  is  obtained  from  the  lower  half  of  the  first 
word  of  the  segment.  A courtesy-call  is  attached  to  the 
Intercom  I/O  so  that  the  output  processor  will  be 
directly  enabled  by  GCOS  when  the  current  Intercom  has 
completed . 

When  the  courtesy-call  is  paid,  the  Intercom 
Status  Return  is  tested  to  see  if  the  Intercom  was 
successful.  If  not  successful,  the  Intercom  is 
reissued.  Otherwise,  the  first  word  of  the  written 
segment,  the  message  segment  linkage  word,  is  copied 
and  the  Output  Buffer  space  assigned  to  the  segment  is 
released.  The  upper  half  of  the  copied  linkage  word  is 
then  examined  to  determine  if  there  is  another  segment 
in  the  message. 

The  linkage  word  holds  a pointer  to  the  next 
segment  of  the  messaqe  if  it  is  nonzero;  otherwise,  the 
linkage  was  extracted  from  the  last  tressage  segment.  If 
there  is  another  segment,  an  Intercom  output  reouest  is 
issued  for  it  with  an  appended  courtesy-call  as  before. 
When  this  Intercom  completes,  a check  is  made  to 
determine  if  there  are  any  more  segments  as  described 
above . 


ihus  the  message  segments  are  serially  written 
until  the  last  segment  is  oetectou  ana,  consequently, 
tlie  wnole  message  has  been  sent.  Wl,en  this  occurs,  the 
output  processor  returns  to  the  Output  Intercom-Queue 
ano  again  fetches  the  highest  priority  queue-entry. 
This  procecure  is  repeated  until  the  queue  is  empty.  At 
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this  Lime,  the  output  processor  disables  itself  by 
terminating  the  courtesy-call  within  an  outstanding 
Intercom  I/O. 


iNotice  that  the  Output  Intercom  Processor  will 
again  be  enabled  at  the  main-level  when  an  output 
request  is  linked  to  the  Output  Intercom-Queue. 
Furthermore,  any  requests  linked  to  the  queue,  while 
the  output  processor  is  enabled,  will  be  retrieved  and 
processed  at  the  courtesy-call  level.  In  the  latter 
case,  the  main-level  enables  associated  with  the  newly 
linked  queue-entries  would  be  ignored. 


Ou^uJ.  Intercom.  Entry  Points 


Symbol  Title 


II0120  Initiate  Output  Intercom 

II0221  Output  Next  Messaoe 

II0130  Output  Next  Nessage  Segm.ent 

IIU131  Reissue  Output  Intercom 

II014U  Output  Intercom  CC 

IlulSU  Check  Intercom  I/O  Status 

IliilGU  Link  Output  Intercom-Queue  Entry 

Ilul7u  Unlink  Output  Intercom-Queue  Entry 


FUNCTION: 


This  routine  initiates  output  Intercom  to  TPE 
provided  that  output  to  intercom  is  not  already 
running.  Output  is  senuenced  by  the  priority 
assianed  to  each  message  when  its  queue-entry  was 
linked  to  the  Output  I ntercor-eueue . Once  started, 
'Output  Intercom  is  driven  at  the  courtesy-call 
level  until  the  Output  Intercom-Queue  has  been 
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emptied.  The  Output  Intercom  routine  empties  the 
Output  Intercom-Queue  from  its  high  priority  tail. 
(It  is  worth  noting  that  each  queue-entry  can 
represent  several  message  segments  within  the 
Output  Buffer,  each  requiring  its  own  Intercom  I/O 
to  send  the  complete  message  to  TPE) . 


ENTRIES: 


EPl  - Initiate  Output  Intercom  (II0120) . 

This  entry  starts  output  Intercom  with  the 
highest  priority  entry  linked  to  the  Output 
Intercom-Queue. 

No  calling  parameters. 

EP2  - Output  Next  Message  (II0121). 

This  entry  retrieves  the  highest  priority 
queue-entry  to  start  output  of  the  next 
message.  The  entry  is  used  only  when  the 
Output  Intercom  Processor  is  at  the 

courtesy-call  level. 

EP3  - Output  Next  Message  Segment  (II0130). 

This  entry  builds  the  necessary  DCW  to  output 
the  next  message  segment  within  the 

queue-entry  being  serviced. 

CPI  - Pointer  to  next  Output  Buffer  message 
segment . 

F.P4  - Reissue  Output  Intercom  (II0131). 

This  entry  reissues  the  Intercom  output 
request  with  the  same  DCW  used  in  the 
previous  issue. 

No  calling  parameters. 


RETURNS: 


Return  is  always  to  the  Call+1 


21 . 5 


OUTPUT  INTERCOM  PROCESSOR 


Outpu t Intercom  CC 


FUNCTION: 


This  routine  checks  the  Intercom  I/O  status  of  the 
previous  GEINOS.  It  the  status  indicates  that  an 
error  has  occurred  in  the  previous  transmission, 
the  previous  Intercom  request  is  reissued  to  GCOS. 
Otherwise,  the  Output  Buffer  space  assignee  to  the 
successfully  written  message  segment  or  message  is 
released,  and  Intercom  I/O  is  issued  for  either 
the  next  message  segment  0£  the  first  segment  of 
the  next  highest  priority  message  linked  to  the 
Output  Intercom-Queue.  This  routine  is 
courtesy-call  driven  and  continues  until  the 
Output  Intercom-Queue  is  empty. 


ENTRIRF : 


EPI  - Output  Intercom  CC  (IT0I40). 

Control  passes  to  this  entry  point  when  GCOS 
services  the  courtesy-call. 


RETURNS: 


Return  is  maoe  to  CCU.S  via  a MME  GEENDC. 
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Check  Intercom  I/O  Status 
FUNCTION: 

This  routine  checks  the  termination,  major  status 
and  lost  interrupt  positions  in  the  first  Status 
Return  word  of  the  specified  Intercom  I/O  request. 

ENTRIES: 

EPl  - Check  Intercom  I/O  Status  (II0150). 

CPl  - First  Intercom  I/O  Status  Return  word. 

RETURNS: 

RRl  - Call+1,  Bad  Status  Return. 

The  Intercom  I/O  must  be  reissued. 

RR2  - Call+2,  Successful. 
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I, ink  Output  I n t er com-O^pup  Entry 
FUNCTION: 


This  routine  links  the  designated  Intercom-Queue 
entry  to  the  Output  Intercom-Queue  according  to 
the  priority  assigned  to  the  queue-entry.  The 
Output  Intercom-Queue  is  ordered  by  ascending 
priority  values  in  the  torward  pointer  direction. 
(See  Queues  aiscussion  tor  the  queue-entry 
iorinat)  . Lastly,  the  count  ot  linked 
Intercom-Queue  entries,  in  cell  .TNSG2  lower  of 
the  indicated  TASK  (it  any),  is  incrementeo . 

ENTRIES: 

EPl  - Link  Output  Intercom-Queue  Entry  (IIG160). 

CPl  - Pointer  to  aueue-entry  to  be  linked. 

CP2  - Pointer  to  associated  TASK,  if  one; 
otherwise,  zero. 

RETURNS : 

Return  is  always  to  Call+1. 
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Unlink  Output  Intercom-Queue  Entry 
FUNCTION: 

This  routine  unlinks  the  designated  queue-entry 
from  the  Output  Intercom-Queue.  The  count  of 
linked  queue-entries,  in  cell  .TMSG2  lower  of  the 
TASK  specified  by  the  queue-entry  (if  any),  is 
decremented  by  one. 

ENTRIES : 

FPl  - Unlink  Intercom-Queue  Entry  (II0170). 

CPl  - Pointer  to  queue-entry  to  be  released. 

CP2  - Pointer  to  the  associated  TASK,  if  one; 
otherwise  zero. 


RETURNS: 


Return  is  always  to  the  Call+1. 


I 
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EXECUTIVE  ERROR  MESSAGES 
Introduction 


Executive  error  messages  are  defined  by  the  .EMSG. 
macro.  This  macro  builds  a table  of  message  DCWs  along 
with  a table  of  the  variable  length  messages.  Message 
DCWs  are  assembled  under  the  ..EXEC  location  counter, 
and  the  actual  message  texts  are  assembled  under  the 
..MSG  location  counter. 


Each  message  is  identified  by  an  associated 
message  code,  which  is  used  as  an  index  into  the  list 
of  message  DCWs.  All  references  within  the  Executive  to 
a particular  message  are  made  with  the  error  code.  This 
code  is  normally  placed  in  TASK  cell  .TERRM  upper  and 
is  used  by  the  TASK  Terminator  to  determine  which 
message,  if  any,  is  to  be  sent  to  TPE  for  a terminating 
transaction . 


There  are  two  special  or  reserved  message  codes. 
Code-l  is  used  to  indicate  that  no  message  is  to  be 
sent  when  the  TASK  is  terminated.  This  code  is  only 
used  when  the  TASK  belongs  to  a spawn  TASK  chain.  It  is 
necessary  to  prevent  a message  with  an 
End-of-Tr ansact ion  (EOT)  status  from  being  sent  to  TPE, 
since  this  would  terminate  the  transaction ' s 
outstandinq  status  within  TPE. 


Code  0 is  used  to  indicate  that  only  a message 
header  specifying  an  EOT  status  is  to  be  sent.  This 
code  is  used  for  TASKS  that  terminate  normally  and  do 
not  belong  to  a spawn  TASK  chain.  Its  effect  is  to 
change  TPE's  processing  status  of  the  terminating 
transaction  to  'completed'. 
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Erro£  Messai^e  Generat^yn 

Error  inessayes  must  be  deiined  in  order  of  their 
assigned  code,  i.e.,  in  message  code  sequence.  There 
can  be  no  missing  cooes.  The  .EMSG.  macro,  with 
descriptive  parameters,  is  invoked  as  follows: 

I 8 16 


.EMSG.  Message-Code, 

ETC  Message-Size, 

FTC  (Message  Text) 

where  the  messaqe  size  is  tjiven  in  words  and  must  be  9 
words  or  I e s :5 . 
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Executive  Error  Messages 

Currently  used  messages,  along  with  their  message 
codes,  are  listed  below; 

Co^  Error  Message 

1 Illegal  MME 

2 Restricted  MME 

3 I/O  Select  Sequence  File-Code  Address  Out 
of  Range 

4 I/O  Select  Sequence  Seek  DCW  Address  Out 
of  Range 

5 Illegal  Seek  DCW 

6 DCW  Data  Address  Out  of  Range 

7 I/O  Select  Sequence  Status  Return  Address 
Out  of  Range 

8 I/O  Select  Sequence  DCW  Address  Out  of 
Range 

9 First  DCW  a TDCW 

10  new  Address  Out  of  Ranae 

11  Two  Successive  TDCWs 

12  Intercom  I/O  Status  Return  Address  Out  of 
Range 

13  Intercom  I/O  DCW  Address  Out  of  Range 

14  Intercom  I/O  DCW  Not  an  lOTD 

15  Intercom  I/O  DCW  Data  Address  Out  of  Range 

lo  Output  Initiated  Before  Input  Requested 

17  Input  Requested  After  Received 
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18 

19 

2U 

21 

22 

2J 

24 

25 

?(> 

21 

28 

29 
.10 

31 

32 

33 

34 

35 

30 

37 

38 

39 


EPROR  MESSAGES 
Illegal  File-Name 

Intercom  Write  DCW  Word  Count  > 12b  Words 

Output  Transaction  tf  Not  Equal 
To  Input  Transaction  » 

Input  Heijuested  Alter  Output  Initiated 

TEAF-To-TEAP  Message  Destination  Count  Not  1 

TEAE-To-TEAE  Message  Keyword  Unknown 

Output  Message  Segment  Destination  Counts 
Disagree 

(^Jinut  Message  Segment  Des t i na t ion- I Ds 
Disanree 

Output  Message  Size  Greater  Than  Execu- 
tive’s Prof  i le 

Input  Messaue  Kevword  Linknown 

Peouested  TPAP  Not  Available 

Fatal  Error  During  Load 

Fatal  Erroi  During  Swai'-Out 

InvaLiu  Serviv’c  Vector 

Logical-ID  Not  3 Characters 

Message  Text  Length  - Character  Count 
Lrior 

KE  to  KE  Message  Logical-ID  Error 
Illegal  Intercom  I/O  CMD 
Outiut  Attempted  After  EOT  Received 
Output  Text  r.ennth  > Message  DCW  Count 
Outnut  Deader  Incomplete 
EO-irp  ^VmorY  Adfkess  Fault 
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40 

Fl-KP 

Fault  Tag  Fault 

41 

F2-KP 

Command  Fault 

42 

F3-KP 

Derail  Fault 

43 

F4-KP 

Lockup  Fault 

44 

F7-KP 

Undefined  OP  Fault 

45 

F8-KP 

OP  Not  Complete  Fault 

46 

F9-KP 

Overflow/Underflow  Fault 

47 

lO-KP 

Divide  Check  Fault 

48 

<<Reserved>> 

49 

F6-KP 

Memory  Parity  Fault 

50  Consecutive  GERELC/GEROADs  With  No 
vening  I/O 

51  File  Control  Block  Out  of  Range 

52  Aborted  By  Keyword  processor  Code 

53  Aborted  <xx> 

54  Invalid  MME  Parameter 

55  Restricted  MME  Option 

56  Resources  Exhausted  - Try  Again 

57  GEPSTR  File-Code  Not  H* 

58  No  Overlays  Declared  In  Profile 

59  No  Overlays  Present  In  Profile 

60  GERSTR  Call  Name  Unknown 

61  GERSTR  Data/Load  Origin  Too  Large 
Assembled  Memory 


Inter- 


XX 


For 


62  GERSTR  I/O  Error 

63  Illegal  DHL 
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64  Restricted  DRI. 


I 
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EXMIOO 

ETXlOO 
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Intercom  Entry  Points 


Title 


Executive  Message  Intercom 
Convert  & Edit  Transaction  Number 
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Fxecut i ve  Message  Intercom 


FUNCTION; 


This  routine  builds  an  output  message  header  using 
the  Transaction  number  and  Source-ID  in  the 
designated  TASK.  The  Transaction  number  is 
converted  to  BCD  and  inserted  into  the  first  two 
words  of  message  text.  Output  buffer  space  for  the 
complete  message  is  requested  and  the  header  and 
text  are  written  to  buffer. 


ENTRIES: 


EPl  - Executive  Message  Intercom  (EXMlOO) . 

CPI  - L(TASK)  to  which  message  applies. 

CP2  - Message  text  PCW.  (If  zero,  only  a 
message  header  will  be  built  and  passed 
to  the  output  buffer). 

CP3  - Message  Status  (FOS,  FOM , or  EOT). 


PFTUPMS : 


RKl  - Call+l,  Sufficient  Output  Buffer  space  not 
aval labl e . 

1!R2  - Cal  1 + 2,  Message  successfully  written  to  the 
Output  Butler.  TASK  cell  .TMSG  holes  a 
pointer  to  the  assigned  buffer  location. 

KPl  - Pointer  to  last  assigned  buffer  cell  tor  this 
message  +1 . 
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Convert  & Edit  Transaction  Number 
FUNCTION: 

This  routine  converts  the  binary  transaction 
number  in  TASK  cell  .TNUMB  to  BCD  and  edits  it 
into  the  form  #-xxxxxxxxxx , where  the  number  is 
left  justified  within  the  x field. 

ENTRIES: 

EPl  - Convert  & Edit  Transaction  Number  (ETXlOO) . 

CPl  - Pointer  to  TASK  whose  .TNUMB 
transaction  number  is  to  be  edited. 

RETURNS: 

Return  is  always  to  call+1. 

RPl  - Edited  transaction  number. 
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EXECUTIVE  SUPPORTED  MME  SERVICE 


Selected  MME  functions  are  supported  by  the 
Executive  in  order  to  mimic  GCOS  MME  processing  for  the 
Keyword  Processors.  An  attempt  has  been  made  to  provide 
a basic  set  of  functions  which  are  normally  required 
and  appropriate  to  the  operating  environment  provided 
by  the  Executive.  The  design  of  the  Executive's  MME 
Identification/Validation  routine  and  of  the  existing 
MME  handlers  is  open-ended  so  that  additional  MME 
functions  or  MME  options  can  be  readily  incorporated. 


The  support  provided  by  the  MME  handlers  varies 
from  completely  processing  the  function  internally  to 
basically  reissuing  the  MME  to  GCOS  after  preprocessing 
the  MME  parameters  in  order  to  maintain  the  integrity 
of  the  Executive's  operating  structure.  Of  those  MMEs 
currently  supported,  various  restrictions  or 
limitations  also  apply  to  the  options  which  are 
otherwise  provided  by  GCOS. 


Control  is  passed  to  the  requested  MME  handler  by 
the  MME  Identification/Validation  routine  within  the 
GELPAR  Fault  Handler. 
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Service  Symbols 

Entry  point  symbols  for  the  MME  services  are 
obtained  troin  the  stanaatd  GExxxx  by  replacing  the  'GE' 
with  '.G',  i.e,,  .Gxxxx.  This  is  done  to  avoid 
duplicate  symbols. 


Symbols  internal  to  the  MME  processors  have  been 
assigned  the  forms  MMEnnx  or  Mnnxxx,  where  nn  is  the 
symbolic  decimal  value  of  the  applicable  GExxxx  symbol. 

M^  Service  Descr  ipt  ions 

Descriptions  of  selected  MME  services  are  found  on 
the  followino  pages.  Detailed  descriptions  are  included 
only  for  those  MME  processors  which  are  somewhat 
involved  or  whose  incorporation  into  the  Executive 
reouires  a multi-faceted  interface. 

Descriptions  for  the  remainder  of  the  MME 
processors  consist  of  a function  statement  along  with 
any  necessary  supporting  information. 
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I/O  Request  Recognition 

The  MME  Identification/Validation  routine  passes 
all  Keyword  Processor  MNF,  GEINOR  faults  to  the  I/O 
Request  Recognition  routine  in  order  to  determine 
whether  the  request  is  for  device  or  Intercom  I/O. 
Prior  to  resolving  the  I/O  type,  a check  is  made  to  sec 
if  a NNF  GFRELC/GFROAD  was  requested  by  the  Keyword 
Processor.  This  is  indicated  if  the  B.TRLO  bit  flag  is 
on  in  TASK  cell  .TFLAG+1.  If  either  a GERELC  or  GEROAD 
has  been  requested,  the  TASK  Status  Flag  is  set  off. 


The  requested  I/O  type  is  then  determined  by 
exaiTiining  the  File-Cooe  in  the  Keyword  Processor's 
Select  Sequence  to  see  if  it  is  the  Intercom 

File-Coue.  Control  is  subsequently  passeo  to  the  Device 
or  Intercom  I/O  Handlers  as  dictated  by  the  designated 
le-Code . 
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P^yiCE  I/O  HANDLER 
MME  GEINOS  Preface 
FUNCTION : 

This  routine  classifies  Keyword  Processor  MME 
GEINOS  requests  as  device  I/O  or  Intercom  I/O.  It 
also  adjusts  the  'MME  GERELC/GEROAD  Requested' 
TASK  Status  Flag  (B.TRLQ)  prior  to  routing  control 
to  the  appropriate  handler. 

FNTRIFS ; 

FPl  - MMF  GEINOS  Preface  (.GINOS). 

CPl  - Pointer  to  the  Keyword  Processor's 
M^'E  + l relative  to  the  Executive. 

CP2  - Pointer  to  the  TASK  renuesting  I/O. 

RETURNS : 

KTl  - Intercom  I/O  Hanuler 

It  the  request  is  for  Intercom  I/O. 

KT2  - Device  I/O  handler. 

If  the  teijuest  is  for  aevice  I/O. 
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Need  for  Executive  Control 


Device  I/O  is  initiated  by  the  Executive  for  the 
Keyword  Processors,  since  they  cannot  be  allowed  to  do 
their  own  I/O.  The  reasons  for  this  restriction  are: 


(1)  All  Keyword  Processor  I/O  Select  Sequence 
parameters  are  relative  to  the  Keyword 
Processor's  GFLBAR,  not  the  Executive's  LAL, 
and 

(2)  The  Select  Sequence  parameters  might  violate 
the  Keyword  Processor's  assigned  memory 
boundaries,  consequently  there  would  be  no 
protection  for  any  other  in-core  Keyword 
Processors  or  the  Executive  itself. 


To  overcome  these  problems  it  xs  necessary  for  the 
Executive  to  preprocess  the  Select  Sequence  paranieter 
and  reissue  the  I/O  request  to  GCOS. 


Executive  I_/0  Administration  Requirements 

Several  administrative  requirements  are  placed  on 
the  Executive  in  order  to  supervise  and  monitor  all 
Keyword  Processor  device  I/O  and  to  maintain  the 
integrity  of  the  operating  environment  it  provides. 
These  reauirements  are  introduced  below  in  terms  of 
their  respective  needs. 


It  is  imperative  that  the  Executive  know  which 
in-core  Keyword  Processors  have  outstanding  device  I/O 
requests  to  allow  the  release  or  reassignment  of  a 
Keyword  Processor's  assigned  core  space.  In  conjunction 
with  this  requirement  is  the  need  for  the  Executive  to 
know  when  each  I/O  completes  so  that  the  outstanding 
I/O  status  of  the  affected  Keyword  Processor  can  be 
adjusted.  This  control  must  be  explicitly  given  to  the 
Executive  when  each  I/O  completes.  Notice  that  since 
the  Executive  initiates  I/O  for  all  the  Keyword 
Processors,  it  cannot  implicitly  determine  when  an  I/O 
completes  by  suspending  itself  with  a relinquish  or 
roadblock . 
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Lastly,  the  Executive  must  be  able  to  determine 
which  Keyword  Processor's  I/O  is  completed  when  it  is 
given  control. 


Multiple  Outstand ing  I/O  Requirements 


Prior  Lo  describing  the  actual  design  of  the 
Executive's  Keyword  Processor  I/O  handling,  the 
problems  associatea  with  allowing  multiple  outstanding 
I/O  need  to  be  addressed. 


If  more  than  one  active  I/O  request  is  to  be 
allowed  each  Keyword  Processor  (rather  than  suspending 
its  execution  from  I/O  request  to  completion),  all 
Keyword  Processor  Select  Sequence  parameters  and  DCWs 
must  be  copied  to  an  Executive  area.  This  is  necessary 
to  prevent  the  Keyword  Processor  from  altering  the 
Select  Seauence  parameters  or  DCWs  while  the  I/O  is 
active.  Copying  the  Keyword  Processor's  DCW  list  would 
be  a problem,  since  the  lists  can  be  of  variable 
length . 


In  addition  to  identifyinq  the  originating  Keyword 
Processor  when  an  I/O  completes,  the  Executive  must 
also  determine  which  of  the  identified  Keyword 
Processor's  outstanding  I/Os  it  is.  This  is  necessary 
in  order  to  know  which  of  the  copied  DCW  lists  is  to  be 
released . 


De^g^n  Decision  & Method 


It  was  oeciaeu  during  ihe  aesign  phase  chat 
multiple  Keyword  Processor  I/O  woula  not  be  initially 
allowed.  Thus  all  Keyword  Processors  are  suspcnoco  from 
execution  when  they  requt.'St  device  I/O  until  the  I/O 
has  completed.  This  decision  was  based  (irimarily  on  the 
observation  that  the  averaqe  or  normal  slave  I/O 
processing  results  in  a relinquish  being  requested 
after  an  I/O  is  initiated.  This  design  decision  does 
not  preclude  the  incorporai  inn  of  s.ueh  a feature. 


The  I/O  administrative  r eqn  i r er  en  t ''  are  effected 
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within  the  Executive  by  attaching  a courtesy-call  to 
all  reissued  Keyword  Processor  I/O  requests.  The 
purpose  of  the  courtesy-call  is  to: 


(1) 

Act  as  a software  interrupt  to  indicate 
some  Keyword  Processor  I/O  has  completed. 

that 

(2) 

Identify  the  Keyword  Processor  that 
the  completed  I/O,  and 

requested 

(3) 

Update  Keyword  Processor  status 
optional  I/O  related  measurements. 

flags 

and 

The  first  function  is  a consequence  of  the 
of  a courtesy-call. 

definition  j 

1 

The 

second  function  is  accomplished 

by 

1 

the 

Courtesy- 

Call  Vector  within  each  TASK. 

When 

the 

Executive 

reissues  the  Keyword  Processor's 

I/O, 

it  j 

attaches 

a cour tesy-cal 1 address 

to 

the  j 

Select-Sequence.  This  address  points  to  cell  .TCCV,  the 
TASK  associated  with  the  requesting  Keyword  Processor. 
The  location  of  the  true  courtesy-call  routine  is 
placed  in  the  Cour tesy-Cal  I Vector. 


When  the  courtesy-call  is  paid,  control  is  passed 
to  the  TASK  Courtesy-Call  Vector.  The  Cou r tesy-Ca  1 1 
Vector  first  sets  an  index  register  to  point  to  cell 
.TCCV+l  of  the  associated  TASK;  it  then  passes  control 
to  the  actual  courtesy-call  routine.  This  routine 
identifies  the  affected  TASK  via  the  previously  set 
index  register,  prior  to  performing  the  third 
courtesy-call  function. 


Executive  I/O  Ugn^linS 

The  Device  I/O  Handler  is  functionally  divided 
into  the  categories  of  I/O  initiation  processing  and 
I/O  termination  processing. 

Initiation  is  triggered  by  a Keyword  Processor's 
I/O  request.  Its  function  is  to  validate  and  adjust  the 
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Keyword  Processor’s  Select-Sequence  parameters,  fill  in 
a skeleton  Se lect-Sequence  within  the  Executive,  attach 
a Courtesy-Call  pointer  to  the  applicable  TASK 
Courtesy-Call  Vector  and  to  issue  the  I/O  to  GCOS.  TASK 
Status  Flag  B.TDIO  in  TASK  cell  .TFLAG  is  set  on  at 
this  time  to  indicate  that  the  Keyword  Processor  has  an 
outstanding  device  I/O  and  is  not  eligible  for 
processor  assignment. 


Tetininarion  is  invoked  when  the  reissued  I/O 
completes.  This  processing  is  performed  by  the 
Courtesy-Call  routine  that  is  attached  to  the  reissued 
I/O  request  via  the  TASK  Courtesy-Call  Vector. 


Device  I/O  Initiation 


The  major  functions  of  the  Initiation  routine  are 

to : 


o Validate  the  File-Code,  DCW  and  Status  Return 
Select  Seouence  pointers  relative  to  the 
Keyword  Processor's  GFLRAF, 


o Ensure 
KPA, 

that 

the  Status 

Return  is 

not 

in 

the 

o Verify 

that 

the  DCW 

dc  f ined 

da  ta 

address 

areas 

KPA, 

lie 

within  the 

GELBAF 

and 

above 

the 

o Relativize  the  ECK  data  adcitcss(es)  within 
the  Keywora  Processot  to  the  Executive's  LAL, 

o Fill  in  the  Executive's  skeleton 

Select-Sequence  witti  all  pointers  relative  to 
the  Executive's  LA[,, 

o Insert  the  adciress  of  the  TASK  Courtesy-Call 
Vector  into  the  skeleton  Select-Sequence  ana 
the  address  of  the  Cour tesy-Cal  I routine  in 
the  Courtesy-Call  Vector, 
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o Set  the  'Device  I/O  in  Progress'  bit  flag  on 
in  the  TASK,  and 


o Reissue  the  I/O  via  the  skeleton 
Select-Sequence . 


Device  1/0  Termination 


The  major  functions  of  the  termination  routine,  which 
executes  at  the  courtesy-call  level,  are  to: 


o Locate  the  affected  TASK  via  the  index 
register  set  by  the  TASK  Courtesy-Call 
Vector , 

o Re-relativize  the  DCW  data  address(es)  within 
the  Keyword  Processor  to  the  Keyword 
Processor's  LAL, 


o Relativize  the  Status-Return  data  address 
residue  to  the  Keyword  Processor's  LAL,  and 

o Turn  off  the  'Device  I/O  in  Progress'  bit 
flag  in  the  previously  identified  TASK. 


Keyword  Processor  Restrictions 


There  are  two  restrictions  that  apply  to  the 
Keyword  Processors  in  regard  to  device  I/O.  First, 
courtesy-calls  are  currently  not  processed  by  the 
Executive.  Second,  all  device  I/O  commands  are  allowed 
except  multi-record  transfers  for  a card  punch,  card 
reader  and  printer. 
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Device  I/O  Hand ler 


FUNCTION : 


This  routine  serves  the  Executive  in  handling  all 
device  I/O  requested  by  the  Keyword  Processors. 
All  I/O  Select-Sequence  parameters  are  validated 
(except  the  courtesy-call  pointer),  relative  to 
the  Executive,  and  inserted  into  a skeleton 
Select-Sequence  used  to  issue  the  I/O  request  to 
GCOS.  The  DCW  list  is  validateo  and  mace  relative 
to  the  Executive.  A pointer  to  the  Device  I/O 
Courtesy-Call  Routine  is  inserted  into  the 
Courtesy-Call  Vector  (.TCCV)  in  the  TASK,  and  the 
location  of  the  TASK  Courtesy-Call  Vector  is 
placed  in  the  skeleton  Select-Sequence  as  the 
courtesy-call  address.  A true  I/O  request  is  then 
issued  to  GCOS. 


Device 

I/O  Ha 

ndler  (D 

lOlOO)  . 

CPl  - 

LAL  of 

request! 

nq  Keyword 

Processor . 

CP2  - 

L(TASK) 

assoc i 

ated  with 

the  Keyword 

Processor . 

CP3  - 

L (NVF) 

relative 

to  the  Ex 

ecu  t ivc . 

RETURNS ; 

Control  passes  from  this  routine  as  follows: 

KTl  - Service  D ispa tcher ' s-Queue . 

If  the  uevice  I/O  v;as  successfully  initiateo. 
KT2  - Start  TASK  Acort. 

It  there  was  an  error  in  the  I/O  request. 
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Validate  DCVv  List 


FUNCTION: 

This  routine  follows  the  DCW  list  given  the 
pointer  to  the  first  DCW  from  the  Keyword 
Processor's  I/O  Select-Sequence.  For  each  DCW  in 
the  list,  its  location  and  the  boundaries  of  the 
region  defined  by  its  data  address  and  word  count 
are  checked  to  ensure  that  they  lie  within  the 
Keyword  Processor's  BAR.  Furthermore,  the  data 
address  region  is  checked  to  ensure  it  does  not 
intersect  with  the  Keyword  Prefix  Area.  The  data 
address  is  then  relativized  to  the  Executive  and 
stored  back  in  the  DCW  list.  Any  errors  cause  the 
TASK  to  be  marked  for  abort. 


ENTRIES : 


EPl  - Validate  DCW  List  (DI0300) . 

CPI  - L (first  Keyword  Processor  DCW). 

CP2  - Pointer  to  TASK  requesting  device  I/O. 


] 

j 


I 


RETURNS : 


RRl  - Call+1,  Successful  validation. 

RTl  - Start  TASK  Abort. 

If  there  was  an  error  in  the  I/O  request. 
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Device  I/O  Cour tesy-Ca 1 1 


FUNCTION: 

This  routine  re-relativizes  each  DCW  in  the 
Keyword  Processor's  DCW  list  to  the  Keyword 
Processor's  PAR  and  stores  the  DCW  back  into  the 
Keyword  Processor's  DC’.'  list.  The  data  address 
residue  in  the  second  Status  Return  word  is  also 
relativizeo  to  the  Keyword  Processor's  DAK  and 
stored  according  to  the  location  specified  in  the 
Keyword  Processor's  I/O  Select-Sequence.  Lastly, 
the  outstanding  device  I/O  bit  flag  in  TASK  cell 
.TFLAG  (3.TDIO)  IS  turned  off. 


ENTkIES: 


EPl  - Device  I/O  Courtesy-Call  (DI04UU) . 

Control  passes  to  this  entry  point  when  GCOS 
services  the  courtesy-call.  The  location  of 
the  affected  TASK  is  recovered  from  the  Index 
Register  set  by  the  Courtesy-Call  Vector  in 
cell  .TCCV  of  the  TASK. 


PFTtlPNS  : 


Control  is  returned  to  GCOS  via  a 'Dip 
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INTERCOM 


Introduction 


All  Keyword  Processor  Intercom  is  treateo  as  a 
pseudo  Intercom  internal  to  the  Executive.  That  xs,  a 
core-to-core  transfer  either  from  the  Input  Intercom 
Buffer  to  the  Keyword  Processor  or  from  the  Keyword 
Processor  to  the  Output  Intercom  Buffer. 


Intercom  Stati^  Flags 


Several  TA.SK  Status  Flags  have  been  defined  to 
identify  the  various  Keyword  Processor  Intercom 
processing  and  message  states.  These  flags  are  used  in 
conjunction  with  TASK  cells  .TMSG,  the  Intercom  message 
descriptor;  .TVSG2,  the  output  message  descriptor 
extension:  and  .Tincw,  the  Pseudo  Intercom  DCW  to 
describe  and  control  each  Keyword  Processor's  input  and 
output  Intercom  processing. 


The  processing  TASK  Status  Flags  are  the  'Building 
Intercom  Output'  flag,  symbolically  denoted  B.TBIO, 
and  the  'Intercom  Output  Complete'  flag,  denoted  by 
B.TOU  flag  is  set  on  when  the  Keyword  Processor  first 
requests  Intercom  output.  The  'Intercom  Output'  flag  is 
set  on  when  an  End-  of-Tr ansact ion  (EOT)  status  is 
uetected  in  an  output  Intercom  message. 


TASK  cell  .TMSG  locates  and  describes  an  input  or 
output  Intercom  message,  depenoing  on  the  Intercom 
processing  status  flags,  whenever  the  cell  is  non-zero. 
TASK  cell  .TNSG2  holds  a pointer  to  the  last  linkeci 
Intercom  output  message  segment  and  the  number  of 
linked  Output  Intercom-Queue  entries  for  this  TASK. 
This  count  is  explained  in  the  Output  Processor 
discussion.  Lastly,  .TIDCW  holds  the  Keyword 
Processor's  pseudo  Intercom  PCK  when  it  requests 
Intercom  I/O, 
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Status  Flags  & Intercom  Output 


When  a Keyword  Processor  requests  Intercom  output, 
a check  is  made  to  see  if  any  output  has  already  been 
sent.  This  is  done  by  testing  the  'Building  Intercom 
Output'  flag  in  the  associated  TASK.  If  the  flag  is 
off,  .TMSG  is  checked  to  see  if  the  input  message  has 
been  requested  (i.e.,  is  zero).  If  .TVSG  is  not  zero, 
the  input  transaction  is  still  in  the  Input  Intercom 
Puffer:  thus,  the  Keyword  Processor  is  attempting  to 
write  Intercom  output  before  requesting  the  input 
transaction  which  it  is  to  process.  This  is  not 
allowed,  so  the  Keyword  Processor  is  aborted. 


If  the  input  transaction  has  been  requested,  i.e., 
.TyiSG  is  zero,  the  'Building  Intercom  Output'  flag  is 
turned  on  to  indicate  that  Intercom  output  has  been 
initiated  by  this  Keyword  Processor.  When  on,  this  flag 
is  additionally  interpreted  to  mean  that  the  input 
transaction  has  been  successfully  passed  to  the  Keyword 
Processor  and  that  TASK  cell  .TMSG  describes  an  output 
Intercom  message. 


For  subsequent  Intercom  output  requests  by  this 
Keyword  Processor,  the  on  status  of  the  'Building 
Intercom  Output'  flag  implies  that  .TMSG  could  already 
describe  the  beginning  segments  of  an  output  message. 
Therefore,  if  .TMSG  is  not  zero,  the  message  being  sent 
by  this  Keyword  Processor  request  will  be  linked  to  the 
last  segment  received.  The  latter  segment  is  located 
via  TASK  cell  .TMSG2  upper.  If  .TMSG  is  zero,  the 
messane  being  sent  will  be  treated  as  the  first  or  only 
segment  of  a new  message,  depending  on  the  message 
status. 


When  an  Intercom  output  m.essaoe  seoment 
specifying  an  EOT  status  is  received,  the  'Intercom 
Output  Complete'  flag  is  set  on  in  the  associated  TASK. 
The  requesting  Keyword  Processor  is  still  eligible  for 
processor  assignment,  even  though  it  has  sent  its  last 
Intercom  Output  message.  This  i.s  cionr  to  allow  it  to 
perform,  any  necessary  wra[;up  processing. 
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Status  Flags  s.  Intercom  Input 


When  a Keyword  Processor  requests  Intercom  input, 
the  'Building  Intercom  Output*  flag  is  tested  to 
determine  whether  TASK  cell  .TMSG  describes  an  input  or 
output  message.  If  the  flag  is  off,  TASK  cell  .TMSG  is 
checked  to  see  if  it  has  been  zeroed  (indicating  that 
the  input  transaction  has  already  been  requested) . If 
.TMSG  describes  the  input  message  (not  zero) , the 
message  is  transferred  via  pseudo-intercom  to  the 
Keyword  Processor.  However,  if  the  message  has  already 
been  requested,  the  Keyword  Processor  must  be  aborted. 


If  the  'Building  Intercom  Output'  flag  is  on,  it 
is  also  necessary  to  check  the  'Intercom  Output 
Complete'  flag.  If  the  latter  flag  is  on,  the  Keyword 
Processor's  transaction  processing  is  considered  to  be 
complete.  Consequently,  the  Keyword  Processor  is 
terminated  normally.  If  the  latter  flag  is  off,  the 
Keyword  Processor  would  be  aborted  because  it  is  trying 
to  process  a new  transaction  before  the  Intercom  ouput 
processing  of  the  original  transaction  has  been 
completed. 


Message  Status  Flags 

The  remaining  Intercom  message  status  flags  are 
the  Input  and  Output  Message  Types,  which  are  denoted 
by  TASK  Status  Flags  B.TITY  and  B.TOTY,  respectively. 
The  Input  Message  Type  flag  specifies  that  the  input 
transaction  lies  in  the  Input  Duffer  when  off,  or  the 
Output  Buffet,  when  on.  An  input  message  in  the  Output 
Buffer  means  that  the  m.essage  was  generated  as  another 
Keyword  Processor's  output. 


The  Output  Message  Type  flag  specifies  that  the 
output  message  is  to  be  sent  to  TPE,  when  off,  or  to 
another  Keyword  Processor,  when  on.  This  flag  is  set  on 
whenever  an  output  message  has  a single  destination-ID 
Qf  '***'  (Keyword  Processor-to-Keyword  Processor 
communication).  This  flag  is  adjusted  for  each  output 
messane  as  required. 
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InLercom  Request  Overview 


All  Keyword  Processor  Intercom  I/O  requests  are 
passed  to  a common  validation  routine.  This  can  be  done 
since  the  format  of  both  the  read  and  write 
Select-Sequences  are  identical.  The  validation  routine 
performs  GELRAR  boundary  checks  on  the  Select-Seouence 
parameters  and  the  DCV\’  defined  data  region.  If  the 
request  is  error  free  the  Intercom  DCW,  always  an  lOTD, 
is  relativized  to  the  Executive's  LAL  and  stored  in 
cell  .TIDCW  of  the  associated  TASK. 


At  this  time  each  Intercom  reouest  is  classified 
as  a read  or  write  according  to  the  I/O  command  in  the 
Keyword  Processor's  Select-Sequence. 


Intercom  Read  Overview 


A Keyword  Processor  Intercom  read  is  always 
considered  to  be  a request  for  its  input  transaction, 
i.e.,  the  transaction  it  is  to  process. 


Vs'hen  a read  request  is  received,  the  Intercom 
processing  status  flags  are  tested,  as  previously 
described,  to  ensure  that  the  request  is  legitimate.  If 
it  is,  the  'Input  Message  Type'  flag  is  examined  lo 
determ.ine  whether  the  input  message  is  in  the  Input  or 
Output  Intercom  Puffer.  If  the  input  message  is  in  the 
input  buffer  {the  flag  is  off),  a pseudo  Intercom 
routine  is  called  to  move  the  message  to  the  Keyword 
Processor.  TASK  cell  holds  the  pseudo-intercom 
•from'  row  and  cell  .TIECw  holds  the  'to'  PCW  for  the 
transfer.  V’hen  the  m.ove  is  complete,  the  Input  Intercom 
Puffer  space  assinned  to  the  requested  inout 
transaction  is  released  (see  Tneut/Output  Intercom, 
Puffer  Vacs  niscussion),  TAEK  cell  .'rvsG  is  zeroed,  and 
a dummy  Ptatus  Return  is  built  and  placed  in  the 
Keyword  Processor  according  to  its  Se  lect-fieouence . The 
Intercom  I/O  Handler  then  returns  control  to  the 
Dispatcher  so  that  a GFvLRAR  can  be  reissued  to  the 
Keyword  Processor. 


II  the  input  ii.essage  is  in  the  output  i-ufter  (the 
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message  type  flag  is  on) , the  input  message  represents 
Keyword  Processor  communication.  In  this  case,  an  input 
message  header  is  built  using  the  output  header  of  the 
first  message  segment  in  the  output  buffer.  The  header 
is  moved  to  the  Keyword  Processor,  after  which  the 
first  segment  is  edited  to  remove  any  leading  blanks 
and  Logical-ID  which  may  preceed  the  message  keyword. 
The  first  segment  is  then  moved  to  the  Keyword 
Processor.  All  character  counts  which  precede  the 
message  strings  that  make  up  the  segment,  are  stripped 
and,  consequently,  not  transferred  as  part  of  the  input 
message.  When  all  message  strings  in  the  segment  have 
been  moved,  the  Output  Intercom  Buffer  space  assigned 
to  the  segment  is  released. 


All  message  strings  of  the  remaining  input  message 
segments  are  also  serially  transferred  to  the  Keyword 
Processor  much  as  the  first,  until  either  the  latter's 
DCW  word  count  tuns  out  or  the  entire  input  message  has 
been  sent.  At  this  time  TASK  cell  .TMSG  is  cleared  and 
a dummy  Status  Return  is  built  and  stored  in  the 
Keyword  Processor  as  dictated  by  its  Select-Sequence. 
The  Intercom  I/O  Handler  returns  control  to  the 
Dispatcher  when  all  processing  has  been  completed  so 
that  a GFLPAR  can  be  reissued  to  the  Keyword  Processor. 


Intercom  Write  Overview 


All  Keyword  Processor  Intercom  Output  requests  arc 
assumed  to  be  output  destined  for  TPE  or  for  Keyword 
Processor  to  Keyword  Processor  communication. 


Vvhen  a write  request  is  received,  the  Intercom 
processing  status  flags  are  tested,  as  previously 
described,  to  ensure  that  the  request  is  legitimate.  It 
it  IS,  the  'Building  Intercom  Output'  flag  and  TASK 
cell  .TMSG  are  examined  to  determine  if  the  beginnings 
of  an  output  message  have  already  been  received.  It  the 
flag  IS  off,  i.e.,  tins  is  the  first  Intercom  output 
request,  or  the  flag  is  on  but  .TMSG  is  zero,  i.e., 
this  is  an  Intercom  output  request  to  start  a new 
output  iTiessage,  the  message  segment's  des t inat ion- 1 D is 
checked  to  see  if  it  is  '***'.  q’his  destination-ID  is 
used  to  indicate  Keyword  Processor-to-Keyword  Processor 
communication.  If  it  is  such  a message,  the  destination 
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count  IS  checked  to  ensure  that  there  is  only  one 
aestination-ID,  and  the  message  keyword  is  extracted 
and  verified  against  the  Executive's  Keywords  List, 
which  IS  located  via  communications  cell  .EKEYL.  If  the 
destination  count  or  keyword  are  in  error,  the  Keyword 
Processor  is  aborted;  otherwise,  the  processing  of  this 
output  request  rejoins  that  of  all  other  output 
messages . 

If  the  'r.uildinq  intercom  Output'  flag  is  on  and 
.TMGSG  is  not  zero,  one  or  more  message  segments  have 
already  been  written  by  the  Keyword  Processor,  In  this 
case,  the  destination  count  and  destination-IDs  of  the 
new  segment  are  matched  against  those  in  the  first 
messaae  segment  to  ensure  that  they  are  the  same.  If 
there  is  a difference,  the  Keyword  Processor  is 
aborted;  otherwise,  the  processing  of  the  output 
request  rejoins  that  of  all  other  output  messages. 


For  all  output  requests,  the  size  of  the  new 
message  segment  is  added  to  the  accumulated  output 
message  size  in  TASK  cell  .TMSG  lower.  The  accumulated 
size  includes  all  message  segment  headers  and  would  be 
zero  for  the  first  segment  of  a message.  The  result  is 
used  to  determine  if  the  cumulative  size  of  all  active 
output  niessage  segments  exceeds  the  maximum  allowable 
size  in  .EMXSZ  upper.  If  the  size  is  exceeded,  the 
Keyword  Processor  is  aborteu;  otherwise.  Output 
Intercom  Buffer  space  is  requesteo  for  the  new  segment. 


If  sufficient  buffer  space  cannot  be  obtained,  the 
executive  will  attempt  to  enlarge  the  output  buffer 
area  by  allowing  it  to  annex  a block  of  core  from  a 
contiguous  free  core  area.  This  will  be  successful 
unless  the  contiguous  core  area  is  being  used. 

If  sufficient  buffer  space  cannot  be  obtained,  the 
'Meed  Output  Intercom  nuffer  Space'  TASK  Status  Flao 
(p.TMPS)  is  turned  on  and  the  T/^SK  Service  Vector  is 
set  so  that  the  processinq  of  the  output  request  can  be 
resumed  at  a later  time  when  the  Intercom  I/O  handler 
is  enabled  by  the  Dispatcher ' s-Cueue  Service.  The 
handler  then  returns  control  to  the  Dispatcher,  since 
further  processinq  is  not  possible. 
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If  sufficient  buffer  space  is  available,  the  space 
is  reserved  by  building  a buffer  map  entry  and  the 
segment  is  then  transferred  from  the  Keyword  Processor 
to  the  Output  Intercom  Buffer  by  the  pseudo  Intercom 
routine.  The  actual  size  of  the  message  segment  is 
stored  in  the  lower  half  of  the  first  word  of  the 
messaqc.  This  size  is  required  by  the  Output  Intercom 
Processor,  which  is  described  later. 


If  the  new  segment  is  not  the  first,  message 
segment,  as  determined  by  TASK  cell  .TMSG,  a pointer  to 
the  new  segment  is  placed  in  the  upper  of  the  last 
linked  segment,  which  is  located  by  cell  .TMSG2  upper. 
Thus  all  output  message  segments  are  linked  together 
via  the  upper  half  of  the  first  word  of  each  message 
segment . 


For  all  output  requests,  the  message  segment 
status  is  examined.  If  the  status  is  End-of-Segment , 
the  Intercom  I/O  Flandler  returns  control  to  the 
Dispatcher.  If  the  status  is  End-of-Transaction , the 
'Intercom  Output  Complete'  TASK  Status  Flag  is  set  on 
and  the  message  status  is  changed  to  an  Fnd-of -Message 
(EOM)  Status.  Fven  after  this  output  message  has  been 
sent  to  TPF,  the  change  of  message  status  allows  the 
Executive  to  also  send  an  Intercom  message  to  TPF, 
which  designates  the  same  transaction  number  as  that 
assigned  to  the  transaction  being  processed  by  the 
reniiesting  keyword  Processor. 


Processing  continues  for  all  message  segments  that 
specified  an  r;CM  status  or  whose  status  was  changed  to 
EOM.  First  TASK  cell  . TVSG  upper  is  cleared,  since  the 
last  segment  pointer  is  no  longer  requited  for  this 
message . 


If  the  message  is  a 'true'  out-ut  message  lor  TPE, 
an  atteiupt  to  get  a free  Output  I ntercoiri-Cueuc  entry  is 
made.  It  the  attempt  is  unsuccessful,  the  TASK  is 
ad]usteu  so  that  the  i.tocessing  can  be  later  resunicd  by 
the  Dispatcher ' s-Cueue  Service.  Otherwise,  the 
queue-entry  is  filled-in  and  linked  to  the  ijut'ue  and 
the  Output  Intercom  Processor  is  enal.'leii.  (See  the 
Output  Intercom  Processor  discussion  for  a further 
explanat  ion.  ) I.astly,  TASK  cell  .T.”SG  is  cleared  for  a 
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new  message  request  and  control  is  passed  to  the 
Dispatcher , 


If  the  message  designated  Keyword 
Processor-to-Keyword  Processor  coiuv.unication,  an 
attempt  is  made  to  obtain  an  unassigned  TASK,  called  a 
spawn  TASK,  is  made.  If  unsuccessful,  the  originating 
TASK  IS  adjusted  so  that  the  Dispatcher ' s-Queue  service 
ran  re-enable  the  processing  at  a later  time. 
Otherwise,  a skeleton  TASK  is  built  in  the  free  TASK 
and  selected  cells  are  copied  from  the  originating  TASK 
to  the  spawn  TASK. 


The  keyword  is  then  extracted  from  the  output 
messaqe  so  that  the  designated  Keyword  Processor 
Profile  can  be  located  and  profile  specifics  inserted 
into  the  spawn  TASK.  At  this  time,  the  'Input  'Message 
Type'  TASK  Status  Flag  is  set  on  in  the  spawn  TASK  and 
the  output  message  is  assigned  to  it  via  its  . TMSG 
cell.  The  spawn  TASK  is  then  linked  to  the  Core-Queue 
and  a conditional  attempt  to  allocate  core  is  made 
depending  upon  the  return  taken  by  the  'Link  to 
Core-Queue'  routine.  Finally,  cell  .TMSG  of  the 
originating  TASK  is  cleared  for  a new  output  message 
and  control  is  passed  to  the  Dispatcher. 
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A 


Intercom  Handler 


FUNCTION: 


This  routine  is  responsible  for  reading  and 
writing  Intercom  messages  to  and  from  a requesting 
Keyword  Processor  using  a MME  GEINOS 
Select-Sequence.  For  input,  the  message  is  passed 
from  the  Input  or  Output  Intercom  Buffer  to  the 
Keyword  Processor  via  pseudo  Intercom.  After  all 
input  is  passed,  the  buffer  space  assigned  to  the 
message  is  released.  For  output,  an  attempt  to 
obtain  Output  Intercom  Buffer  space  is  made  and, 
if  successful,  the  message  segment  is  moved  to  the 
output  buffer  and  linked  to  the  previous  message 
segment,  if  any.  If  the  message  segment  status  is 
End-of-Message  or  Transaction,  an  attempt  is  made 
to  obtain  an  Output  Intercom-Queue  entry  and,  if 
successful,  the  queue-entry  is  linked  to  the  queue 
and  the  Output  Intercom  Processor  is  enabled. 
Keyword  Pr ocessor-to-Keyword  Processor 
communication  is  also  handled  by  this  routine. 


ENTRIES: 


Common  calling  parameters  are: 

CPI  - Pointer  to  TASK  associated  with  the 
Keyword  Processor  requesting  Intercom 
I/O. 

CP2  - L(MME)+1  relative  to  the  Executive. 


EPl  - Intercom  I/O  Handler  (IlOOlO). 


EP2  - Restart  Intercom  I/O,  Need  Output  Buffer 
Space  ( 1 10052) . 

Control  passes  to  this  entry  point  from  the 
Dispatcher ' s-Queue  Service. 
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(II0082) . 

Control  passes  to  this  entry  point  from  the 
Dispatcher ' s-Queue  Service. 

EP4  - Restart  Intercom  I/O,  Need  Intercom  Q-Entry 
(II0083) . 

Control  passes  to  this  entry  point  from  the 
Dispatcher ' s-Queue  Service. 

RETURNS: 

Control  passes  from  this  routine  as  follows: 

RTl  - Reissue  GELBAR  After  Service  (DSP302) . 

Intercom  was  successfully  completed. 

RT2  - Service  Dispatchers-Queue  (DSP102) . 

Intercom  could  not  be  completed. 

RT3  - Start  Task  Abort  (TRMlOO). 

Error  in  request. 

RT4  - Start  TASK  Termination  (TRM400) . 

Intercom  read  after  all  Intercom  output  has 
been  completed. 
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FUNCTION: 

This  routine  validates  the  Intercom  I/O 
Select-Sequence  parameters,  relativizes  the 
Keyword  Processor's  lOTD  DCW  data  address  to  the 
Executive  and  saves  the  DCW  in  the  associated 
TASK'S  .TIDCW  cell.  Lastly,  the  IC  in  TASK  cell 
.TICI  is  bumped  to  point  to  the  first  word 
following  the  Select-Sequence. 

ENTRIES: 

EPl  - Validate  Intercom  I/O  (II0090). 

CPI  - L(TASK)  requesting  Intercom  I/O. 

CP2  - L(MKE)+1  relative  to  the  Executive. 

RETURNS: 

Return  is  made  to  the  calling  routine  as  follows: 
RRl  - Call+1,  Error  in  request. 

RR2  - Call+2,  Successful. 
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Pseudo  Intercom 


FUNCTION: 


This  routine  effects  a core-to-cote  data  transfer 
as  dictated  by  the  designated  'from'  and  'to' 
DCWs.  At  the  completion  of  the  transfer,  the  data 
adoress  and  wore  count  of  both  DCWs  are  adjusted 
to  reflect  the  move.  The  woru  count  used  in  the 
transfer  is  always  the  smaller  of  the  two  DCW  word 
counts,  where  a word  count  of  zero  is  taken  to  be 
zero  unlike  a normal  DCW. 


ENTRIES: 


EPl  - Pseudo  Intercom  (IlOlOO). 

CPI  - Pointer  to  the  'from'  DCW. 
CP2  - Pointer  to  the  'to'  DCW. 


RETURNS : 


Return  is  always  made  to  the  Call+l. 
RPl  - number  of  word  transferred. 


23.24 


EXECUTIVE  SUPPORTED  MME  SERVICES 


Pseudo  Intercoin  Wr apup 


FUNCTION; 


This  routine  builds  a pseudo  Status  Return  for  a 
Keyword  Processor  that  has  requested  intercom  I/O. 
The  result  is  stored  in  the  Keyword  Processor 
usinq  the  Status  Return  pointer  given  in  its 
Select -Seauence. 


ENTRIES : 

EPl  - Pseudo  Intercom  VJrapup  (IIOIIO). 


CPI 

- Pointer  to 

Status  Return 

in 

the 

requesting 

Keyword  Processor. 

CP2 

- Pointer  to 

the  Keyword  Processor's 

DCW 

used  in  the  pseudo  Intercom 
CP3  - Pointer  to  the  associated  TASK. 


RETURNS: 


Return  is  made 


to  the  Call+1. 
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MMF  GFFCON  Handler 
FUNCTION; 


This  routine  follows  the  chain  of  File  Control 
Blocks  (FCH) , if  any,  starting  with  the  FCB 
pointed  to  by  Q-upper  in  the  designated  Keyword 
Processor's  register  storage  area  (.KHEG).  For 
each  FCB,  its  range  from  LOCSYM-7  to  LOCSYM  and 
Its  'next  FCB  pointer'  in  LOCSYM-1  are  checked  to 
ensure  that  they  are  within  the  Keyword 
Processor's  BAR.  The  'next  FCB  pointer'  is  then 
relativized  to  the  Executive's  LAL.  The  FCB  chain 
is  followed  until  the  'next  FCB  pointer'  is  zero 
or  points  to  the  first  FCB. 


When  all  FCB  pointers  in  the  chain  have  been 
relativized  to  the  Executive,  a true  MFE  GEFCON  is 
issued.  Upon  return,  all  FCB  pointers  in  the  chain 
ate  re-reliit  ivized  back  to  the  Keyword  Processor's 
LAI,  and  the  GFLRAR  is  reissued. 


FNTPIF.^  : 


FPl  - WMF  GFFCON  riandl^r  (.GFCO"'). 

CPI  - Pointer  to  TAFK  renuesting  the  MME 
GEFCON. 


RETURNS : 

RTl  - Reissue  GELBAR  After  Fault  (DSP3U3) . 

If  a valid  request. 

RT2  - Start  TASK  Abort  (TKMlUU). 

If  an  error  in  the  request. 
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MME  GEINFO  Handler 


FUNCTION: 


This  routine  processes  Keyword  Processor  MME 
GEINFO  List  Function  requests.  The  SSA  Copy 
Function  is  not  allowed. 


The  Keyword  Processor's  Directive  List  boundaries 
are  checked  to  ensure  that  the  list  lies  within 
the  assigned  core  area.  Each  directive  is  then 
processed  with  the  directive's  information  address 
(1  word)  and  specified  option  validated. 

Currently,  only  Option  10,  Configuration  data  from 
.CRFIG,  and  Option  12,  Program  Number  from  SNUMB 
are  implemented.  For  the  latter  option,  the  SNUMB 
is  restricted  to  $ TRAX. 


ENTRIES: 


EPl  - MME  GEINFO  Handler  (.GINFO). 

CPl  - Pointer  Keyword  Processor  MME+1 . 
CP2  - Pointer  to  associated  TASK. 


RETURNS : 

RTl  - Reissue  GFLRAP  After  Fault  (DSP303) . 

If  a valid  request. 

RT2  - Start  TASK  Abort  (TRMlOO). 

If  an  error  request. 
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i 


1 

WMF  GELAPS  Handler  ^ 


FUNCTION; 

Elapsed  processor  tiire  for  the  reouesting  Keyword 
Processor  is  copied  from  the  .TLAPS  cell  of  the 
associated  TASK  to  word  5 of  the  Keyword 
Processor's  processor  register  storage  area  at 
.KREG  in  its  Keyword  Processor  Prefix. 


ENTRIES : 

EPl  - MME  GELAPS  Handler  (.GLAPS). 

CPI  - Pointer  to  the  TASK  associated  with  the 
requesting  Keyword  Processor. 


RETURNS: 


Return  is  always  made  to  the  'Reissue  GELPAR  After 
Fault'  (DSP303)  entry  point  in  the  Dispatcher. 
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MME  GERELC/GEROAD  Handler 


FUNCTION: 


This  routine  handles  Keyword  Processor  MME  GERELC 
or  GEROAD  faults.  The  'MME  GERELC/GEROAD 
Requested'  flag  (B.TRLQ)  setting  in  the  associated 
TASK  is  checked  first.  If  off,  the  flag  is  set  on 
and  control  passes  to  the  Dispatcher  to  reissue 
the  broken  GELBAR.  If  the  flag  is  on,  the  Keyword 
Processor  is  flagged  for  abort. 


The  'MME  GERELC/GEROAD  Requested*  flag  is  turned 
off  by  the  MME  GEINOS  Preface  whenever  I/O  is 
reouested . 


ENTRIES : 


EPl  - MME  GERELC/GEROAD  Handler  (.GRELC  or  .GROAD) . 

Entry  is  always  made  from  the  GELBAR  Fault 
Hand ler . 

CPI  - pointer  to  Keyword  Processor  MME+1. 

CP2  - Pointer  to  associated  TASK. 


RETURNS : 


RTl  - Reissue  GELBAR  After  Fault  (DSP3U3) . 

If  TASK  Status  Flag  B.TRLO  is  off. 
PT2  - Start  TASK  Abort  (TRMlOO). 

If  P.TRIiO  is  on. 
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MME  GFTIME  Handler 


FUNCTION’: 


A true  MMF  GFTIl'^F  is  issued  for  the  requesting 
Keyword  Processor  with  the  resulting  date  and  tine 
stored  in  words  4&5  of  the  Keyword  Procesor's 
processor  register  safe-storage  area  (.KRFG), 


ENTRIES: 


EPl  - MME  GETIME  Handler  (.GTIME). 

CPI  - Pointer  to  requesting  TASK, 


RETURNS : 


Return  is  always  made  to  the  'Reissue  GELEAR  After 
Fault'  (DSP303)  entry  point  in  the  Dispatcher. 
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5^E  GEWAKE  Handler 
FUNCTION : 

This  routine  mimics  a true  MME  GEWAKE  by 

suspending  the  requesting  Keyword  Processor  from 
execution  for  the  specified  time  interval.  If  the 
time  interval  is  greater  than  1 second,  the 
Keyword  Processor  is  marked  eligible  for  swap. 

ENTRIES : 

Common  calling  parameters  are: 

CPI  - Pointer  to  TASK  requesting  a GEWAKE. 

FPl  - MME  GEWAKE  Request  Handler  (.GWAKE). 

This  entry  is  used  to  service  the  initial 
GEWAKE  reouest. 

EP2  - Awaken  Keyword  Processor  (MME283) . 

This  entry  is  used  to  awaken  a Keyword 
Processor  when  the  TASK  Alarm  Clock  (.ETACK) 
r ings . 

RETURNS : 

RTl  - Start  TASK  Abort  (TKMlUU) . 

If  an  error  in  the  request. 

RT2  - Reissue  GFLPAR  after  Fault  (DSP303) . 

If  zero  wait  time  interval. 

RT3  - Service  Dispatcher ' r-Cueue  (DSP102). 

If  non-zero  wait  time  interval. 
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Prototype  MME  GEROUT  Handler 


FUNCTION: 


This  routine  processes  MME  GEROUT  requests. 
Presently,  only  the  Direct  Access  Output  (operation 
code  3)  and  the  Direct  Access  Output/Input  (operation 
code  4)  functions  are  handled.  The  routine  is  designed 
to  allow  easy  incorporation  of  subprocedures  for 
processinq  other  operation  codes. 


When  a GF.KOUT  request  is  received,  address  and 
boundary  checks  are  applied  to  the  GEROUT  record 
point-or,  status  return  word  pointer  and  input  buffer 
pointer,  if  appropriate.  The  'PeiTiote  I/O'  TASK  status 
bit,  B.TRIO,  is  set  true,  after  which  the  Remote  I/O 
Supervisor  is  called  to  initiate  the  GEROUT  function. 
Upon  return,  control  is  transfecteu  to  the  Dispatcher 
since  the  proyram  requesting  the  GEROUT  cannot  be 
alloweu  to  execute  until  the  I/O  is  coinplete. 


The  GEROUT  handler  again  regains  control  when  it 
is  paid  its  courtesy-call  by  the  Remote  I/O  Supervisor. 
At  this  time,  any  GEROUT  parameters  which  were  made 
absolute  prior  to  starting  I/O  are  made  relative  to  the 
requesting  program's  LAL,  the  GEROUT  status  return  is 
inserted  according  to  the  MME  GEPOUT  status  return 
pointer,  the  'Pc'mote  I/O'  TASK  status  flag  is  set  false 
and  the  faulting  program's  IC  is  positioned  past  the 
MME  calling  sequence. 


ENTRIES ; 


EPl  - NfiE  GEROUT  Handler  (.GROUT) 

CPI  - Pointer  to  faulting  program's  MME+1  . 
CP2  - Pointer  to  associated  TASK. 

EP2  - NME  GEROUT  Cou r tesy-Ca  1 1 (.■'.M305d)  . 

CPl  - Terminal  Control  P>lock  Pointer. 
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CP2  - GEROUT  Status. 

CP3  - GEROUT  Status  Offset. 

This  offset  reflects  the  bit  position, 
relative  to  the  least  significant  bit, 
of  the  most  significant  bit  set  true  in 
the  status. 

RETURNS: 

RTl  - Service  Dispatcher ' s-Queue  (DSP, 2) 

RT2  - Start  TASK  Abort  (TRM,1) 
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MME  GERSTR  Handler 


FUNCTION: 


This 
GERSTRs. 
must  have 
Prof i le . 


routine  handles  Keyword  Processor  MME 
The  Keyword  Processor  requesting  the  GERSTR 
the  overlay  declared  in  the  Keyword  Processor 


The  overlay 
overlay  name, 
determined  using 
origin  and  size 
will  reside  with 
Processor.  The 
continues  accord 


entries  are  scanned  for  the  requested 
If  found,  the  origin  and  size  are 
the  normal  GCOS  conventions.  Then  the 
are  checked  to  ensure  that  the  overlay 
in  the  assigned  core  for  the  Keyword 
overlay  is  then  loaded  and  processing 
ing  to  GCOS  conventions. 


ENTRIES : 


EPl  - MME  GERSTR  (.GRSTR) 

Normal  GECOS  calling  parameters  ate  assumed. 
CPI  - Pointer  to  TASK  requesting  a GERSTR. 


RETURNS: 


Returns  follow  the  normal  GCOS  conventions  for 
*CFRSTR'  processing. 

PTl  - Reissue  GFLPAP  after  Service  (DSP302)  was 
successfully  completed. 

FT2  - Start  Task  Abort  (TPMlOO)  if  an  error 
occurred  and  there  was  no  error  handling 
capability  in  the  GERSTR  request. 
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Introduction 


The  Executive  performs  a one-pass  initialization 
of  its  control  functions  and  the  Keyword  Processors  it 
is  to  manage.  The  Initialization  Routine  is  attached  to 
the  main  body  of  the  Executive  as  a linked  module,  that 
is  by  means  of  a ^ LINK  control  card.  This  is 
intentionally  done  to  force  all  System  Library 
subroutines,  which  are  called  by  the  Executive  proper, 
to  be  loaded  directly  behind  (above)  the  Executive's 
main  body  and  before  (below)  the  Initialization 
Routine.  At  the  end  of  the  initialization  phase,  the 
core  space  used  by  the  Initialization  Routine  becomes 
part  of  the  swap  cote  area.  Any  error  conditions 
detected  during  the  Executive's  initialization  are 
communicated  to  the  console  typewriter  via  error 
messages.  When  and  if  the  Executive  is  ready  to  begin 
processing,  a start  message  is  sent  to  the  console 
indicating  that  the  initialization  was  successful.  Due 
to  this  procedure,  it  is  suggested  that  the  Executive 
be  initiated  from  the  system  console. 


Overview 


The  major  functions  performed  by  ini t ia I i za t ion 
are  as  follows: 


- Get  $TRAX  program  number 

- Initialize  the  fault  vectors 

- Initialize  the  LOAD  and  SWAP  files 

- GECALL  the  Keyword  Processors 

- Upaate  the  Keyword  Processor  Profiles 

- Write  Keyword  processors  to  t)ie  LOAD-File 

- Release  excess  LOAD-I’i  le  space 

- Set  controls  for  the  Core  ana  Swap  tables 

- Assign  input  buffet  space 

- Assign  cote  space 

- Assign  output  buffer  space 

- Send  messages  to  the  console 


The  GFLRAR  fault  vector  within  the  Slave  Prefix 
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Area  (location  19/10)  is  enabled  in  the  Executive  in 
order  for  it  to  process  any  program  errors  that  are 
detected  in  its  Keyword  Processors.  This  is  necessary 
because  the  Keyword  Processors  are  operating  within  a 
GELBAR  environment,  and  aborts  have  to  be  controlled  by 
the  Executive.  Recall  that  the  GCOS  operating  system 
knows  and  would  abort  a program  by  its  program  number, 
which  in  this  case  is  assigned  to  the  Executive.  A 
precaution  was  added  to  the  Intercom  (F/8)  logic  in  TPE 
to  enhance  the  security  and  control  of  interprogram 
communication.  This  control  necessitates  that  the 
program  number,  which  is  to  be  communicated  with,  be 
inserted  into  the  Intercom  Select-Sequence  I/O  command. 
The  program  number  is  requested  by  SNUMB  ($TRAX)  using 
Option  12  of  the  MME  CEINFO.  ^he  number  is  set  into  the 
necessary  Intercom  Select-Seauences  with  the  Executive. 


The  LOAD-File  and  SVJAP-File  are  attached  to  the 
Executive  via  the  $ FILE  control  card.  The  file  codes 
for  these  files  are  ?L  and  $S  respectively.  Both  files 
should  be  allocated  to  the  fastest  device  available 
which  has  a block  size  of  sixty-four  words.  The 
LOAD-File  is  used  to  save  an  initial  or  clear  copy  of 
the  Keyword  Processors  which  are  GECALLed  (see  next 
paragraph)  by  the  Executive.  The  SWAP-File  is  used  to 
save  the  working  copies  of  fvcywora  Processors  and  their 
Keyword  Prefix  Area  when  they  ate  suspended  from 
execution.  The  file  attributes  of  both  files  are 
obtained  during  initial ization  via  HME  GEFADCs.  If  the 
file  does  not  exist,  a MNE  GEMOHE  is  requested  to  get  a 
new  file.  It  is  suggested  that  a large  number  of  blocks 
be  allocated  to  the  LOAD-File,  so  that  the  space  will 
not  be  exhausted  during  initialization.  If  the  space 
runs  out,  additional  space  is  requested  via  a MME 
GEFOKE;  however,  such  a request  could  be  denied.  Any 
excess  LOAD-File  space  will  be  released  via  a KME 
GERFLS  after  all  Keyword  Processors  have  been  copied 
onto  the  file. 


7he  start  inq  address  of  the  Keyword  Processor 
Profilf^  Table  is  located  in  cell  .fpPFL  of  the 
Executive  Communication  Peaion.  The  size  of  the  i^rofile 
entries  are  fixed.  The  maximum  input  and  output  message 
sizes  expected  by  each  Keyv/ord  Processor  ore  inserted 
in  the  profiles  at  generation  time  with  the  .PFFL. 
macro.  Both  sizes  must  be  compared  to  the  maxinur  size 
allowed  by  the  Executive,  as  rccordeo  in  .i.’hXFZ,  to 
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verify  that  they  are  not  larger.  If  either  size  is 
larger,  the  Keyword  Processor  is  rejected  and  a message 
is  sent  to  the  console  to  that  effect. 


The  iden t i f ica t ion  of  the  Keyword  Processors  to  be 
managed  by  the  Executive  are  assembled  into  their 
respective  Keyword  Processor  Profiles  during  the 
generation  phase.  The  Keyword  Processor  IDs  are  used 
within  a MME  GFCALL  to  load  the  program  into  the 
Executive's  high-core  The  $L  seek  addresses  a<'e  placed 
in  the  respective  profiles  for  future  reference  by  the 
Executive.  The  rationale  behind  this  LOAD-File 
arrangement  is  that  subsequent  I/O  requests  for  the 
Keyword  Processor  can  be  made  with  a MME  GEINOS  rather 
than  a MME  GECALL.  This  is  beneficial  since  the  GECALL 
must  search  a catalog  in  order  to  locate  the 
appropriate  DCWs  to  load  the  named  file.  On  a 
normal  GECALL  return,  the  program  size  is  checked  to 
determine  if  it  will  fit  the  maximum  core  requirements 
based  on  the  number  of  DCWs  that  can  be  built  in  its 
Keyword  Prefix  Area.  If  it  cannot  be  built,  it  is 
rejected  and  a message  is  sent  to  the  console.  If  it 
can,  the  Keyword  Processor’s  profile  is  updated  to 
reflect  its  size  and  entry  address  along  with  the 
LOAD-File  address. 


The  program  size  is  then  checked  against  the 
remaining  number  of  blocks  (LLPLKs)  in  the  LOAD-File  to 
determine  if  there  is  sufficient  space.  Tf  space  is  not 
sufficient,  a GFMOPF  is  executed  to  obtain  additional 
blocks.  A dummy  TAFK  is  formatted  in  order  to  use  the 
Core  Allocator's  I/O  Holl-out  routine  to  v;rite  the 
Keyword  Processor  to  the  LOAD-File.  The  fields  that 
must  be  set  in  the  TA.SK  are  the: 


(1) 

'hew  TASK'  oit  Llag 

(B .TNUT) 

in  .TFLAG+1 

(2) 

^L  seek  auoress  in 

.TSV\AP 

upper  and 

program  size  in  .TSW 

AP  lov.ek 

(3) 

GECALL  LAL  in  .'ILAL 

lower  . 

In  auaition,  a Mim!,  GLl.NDC  is  placeo  in  TAdU  cell 
.TCCV,  the  Cout tesy-Ca 1 I Vector,  since  a courtesy-call 
IS  not  rcc:uireo.  To  coi,  plete  this  processing  phase,  a 
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call  to  the  Roll-out  routine  is  made  ana  the 
Initialization  Routine  is  toadblocked  awaiting  the 
completion  of  the  write. 

If  there  is  an  error  in  the  GECALL  or  Roll-out, 
the  profile  is  cleared  and  a message  is  sent  to  the 
console.  When  all  the  profiles  have  been  cycled  the 
excess  LOAD-File  space  is  released  via  a MME  GERELS. 

The  Executive  Communication  Region  is  updated  with 
the  parameters  needed  to  control  the  utilization  of  the 
Swap-File  and  the  swap  core  area.  For  the  Swap-File, 
the  number  of  free  64-word  blocks  is  placed  in  .ESNAP 
as  the  size  of  the  Swap-File  and  also  as  the  upper 
address  limit  of  the  file.  .ESMAP  is  a four  word  field 
that  contains  the  base  Swap-File  Map  entries. 


The  TPOS  Executive  then  establishes  the  following: 

o Input  buffer  area 
o Available  core  area 
o Output  buffet  area 


The  starting  adoress  for  the  input  buffer  is 
calculated  by  determining  the  address  of  releasable 
core.  The  coue  in  the  TPOS  Initialization  Routine  is 
diviued  into  two  areas: 

o Cone  to  create  the  available  areas 
o Code  to  perform  the  other  initialization  functions 

The  beginning  address  of  the  input  buffer  area  is  set 
at  the  beginning  of  'Code  to  perform  the  other 
initialization  functions'.  The  amount  of  space  needed 
is  calculated  as  follows: 

Recommended  Input  Intercom  Puffer  Space  (See  Site 
(Reference) 

+ 1.5  * maximum  input  message  size 

+ the  number  of  words  to  round  to  the  beginning  of  the 

- 

Total  used  for  the  Input  buffer  space 
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LAST  ENTRY 


INPUT  SUFFER 
THRESHOLD 


LAST  ENTRY 


THKESliCLD 

ENTRY 


1 

1 

INPUT  1 

PUFFER  1 

i 

1 

?^PZ  "T 

1 

1 

1 PTR  TO 

1 

1 1 

1 .FIMAP 

1 RESV  1 

1 

THRESH  1 

1 

1 

1 NUMBER 

1 

WORDS  T NUMBER  OF  1 

lAT  INIT.  1 WORDS  NOW  I 

1 ( 1 

1 

1 PTR  TO 

1 1 
1 UNUSED  1 

1 START 

BUFFER  1 1 

1 

INPUT  1 

1 

buffer  1 

1 

1 

THRESHOLD  1 

1 

T 

AVAILABLE  “T 

1 

CORE  1 

i 

AVAILABLE  1 

1 

CORE  1 

1 

1 

OUTPUT  1 

nUFFFR 

i 

THRESHOLD 

1 

I 

1 

1 

OUTPUT  1 

1 

i 

PUFFFR  1 

i 

1 

1 

MPZ  1 

1 

1 

1 PTR  TO 

1 1 

1 . EG^;AP 

1 1 

1 

1 

TliKbSn  1 

1 

1 

1 NUMPbK 

1 

WORDS  1 NUMBER  OF  1 

lAT  INIT.  1 WORDS  NOV,  1 

1 1 

1 

1 PTK  TO 

1 

1 UNUSED  1 

1 START 

BUFFER  1 [ 
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The  ending  address  of  the  Output  Intercom  Buffer 
is  the  UAL  (found  in  word  31  (decimal)  of  the  slave 
prefix  area).  The  beginning  address  of  the  Output 
Intercom  Buffer  is  calculated  as  follows: 


The  UAL 

- the  recommended  size  of^  the  Ou^puj.  Intercom  Buffer 
Subtotal 

- The  number  of  words  necessary  to  round 
down  to  the  next  even  IQ24-word  block 
Beginning  address 

A threshold  area  is  created  for  both  the  Input  and 
Output  Intercom  areas.  The  threshold  is  currently  set 
to  1.5  times  the  maximum  input/output  message  size. 


The  size  of  the  threshold  area  is  subtracted  from 
the  input  buffer  upper  address  limit.  The 
ini t ia 1 i za t ion  of  the  input  buffer  and  input  buffer 
aueue  is  completed. 


The  core  area  is  then  reserved  and  the  core-oueue 
and  maximum  core  size  are  initialized. 


The  Output  Intercom  queue,  the  output  thresholo  area 
and  the  Output  Intercom  area  are  then  initialized. 

At  the  coriipletion  of  the  Lxecutive's 
Initialization,  a start  message  is  sent  to  the 
operator's  console. 
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Initialization  Console 


Messages 


Several  messages  can  be  issued  to  the  console  in 
response  to  various  conditions  that  can  be  encountered 
during  initialization.  A list  of  current  messages 
follows.  The  SN[JMn  is  that  assigned  to  the  Executive. 

SNUMP**RFSTART  TRAX 

SNUMP*INSUFFICIENT  LOAD-FILE  FOR  TPOS  EXFC 
SNUMR*NO  SWAP  FILE  FOP  TPOS  EXFC 
SNUM3*K.P.S.xxx  INPUT  BUFFER  TOO  LARGE 
SNUfiB*K.P.S.xxx  OUTPUT  PUFFER  TOO  LARGE 


SNUMB*K.P.S.xxx  TOO  LARGE 
SNUMB*K.P.S.xxx  GECALL  ERROR 
SNUMB*K.P.S.xxx  LOAD-FILE  ERROR 
SNUMB*NO  ACTIVE  K.P.  FOR  TPOS  EXEC 
SNUMB*TPOS  EXECUTIVE  INITIATED 


Where  xxx  is  the  Keyword  Processor's  ID. 
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